Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!xylogics!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.questions Subject: Re: Why /etc/mtab? (was: Example modification of /etc/mtab wanted) Message-ID: Date: 2 Jun 90 20:08:29 GMT References: <1678@trlluna.trl.oz> <1918@aurora.cs.athabascau.ca> Sender: bzs@world.std.com (Barry Shein) Followup-To: comp.unix.questions Organization: The World Lines: 39 In-Reply-To: lyndon@cs.AthabascaU.CA's message of 31 May 90 21:36:50 GMT >Which leads me to pose the question: > > Why does Unix use a file to store mount information? > >It seems to me that the proper way to determine what's mounted would >be to look in the kernel mount tables. It would be trivial to implement >a system call to return the information. Anyone know why the "ask the >kernel" approach was never taken? It goes way back to the early Unix days, V6 on the PDP-11 certainly had /etc/mtab. With a maximum of 64KB for the kernel you made trade-offs, one of Unix's early plus's was how much it used facilities outside the kernel to get things done. Design goals were also compelling. Of course, in this day and age it seems like a minor savings, but you could probably find dozens of things like this to put in the kernel if you looked around. The bloat would start to get real (why not store environment variables in the kernel so children can set parent processes? How about the password/group file? host tables? Heck, everything YP manages? etc etc.) There are a lot of us out there who hope the trend would be quite the other way, more for design reasons than memory concerns. Things in the kernel tend to quickly become immutable in various ways. Putting things in the kernel tends to make innovation impossible unless you're a kernel hacker (and have the sources, time and energy.) Just changing, e.g., the way a few fields in a text file are handled is not very hard if you wanted to extend mount table semantics. What you really want is just a putmountent() library to hide the details of the service, not to redesign Unix to make it easier to write that one library call. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD