Why /etc/mtab? (was: Example modification of /etc/mtab wanted)

[Barry Shein]

>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 at world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD