silver@csu-cs.UUCP (06/21/83)
Here are the questions I asked about /etc/mnttab vs. the internal mount table kept in the kernel: 1: Are there any other good reasons for the tables to be separate, or is this YAHK (yet another historical kludge)? 2: We're considering a kernel mod so you can either read the internal table directly (via a new intrinsic) or have accesses to /etc/mnttab magically reference the internal table, which would always contain the root volume as the first entry. Writes to the table would appear to succeed but change nothing (which makes setmnt obsolete). Do you see any difficulties with these approaches, or the general idea of merging tables? I received about five responses (thanks!). Here is a summary; sorry for not condensing it further: The reason for the separate table (modulo name changes, it's been in every version of UNIX I know about) is that the internal table maps the inode pointer of a mounted-on inode to the device number of the device mounted on it. You would have to stick the pathname of the mount point into the mount table entry, and either search "/dev" for the mounted device or stick its pathname into the mount table too. I guess they figured it wasn't worth munging the "mount" system call for the relatively slight benefit of eliminating the on-disk mount table. I disagree, and think keeping the mount table 100% in core is probably a good idea; yes, it's a relatively slight benefit, but then it isn't TOO much work. I see no reason why it wouldn't work; 4.1BSD does stick the last component of the mount point's path into the super block (instead of sticking the "file system name", which is supposed to be the last component of the mount point's path, and the "volume name" there). Of course, this doesn't explain why 4.1BSD has "/etc/mtab" like every other Research system, instead of searching the in-core table and sucking the pathname out of the superblock... P.S. I'd suggest using a "table" device driver, where the minor device would select which kernel table to read from. This would make it convenient for processes like "ps" to get at system tables. The mount table would be another such table. --- Why not treat the table like many other user level programs which want to read stuff in the UNIX kernel do? Make the table readable in /unix, then read the symbol table from /unix; open /dev/kmem for reading and seek to the indicated offset. see /etc/crash. --- It seems that a reasonable approach to a "perfectly correct" /etc/mnttab would be not to add a new intrinsic, but instead to make it a pseudo-device, like /dev/kmem, etc. [I think that some good means of perusing the system tables is good, and for non-sensitive information, this is fine. A better (highly restrictive) peek (and even poke if you desperately want it) mechanism should be there so you can look at only those parts of kmem that you ought to.] In fact, building a kmem-like driver which only allows access to part of kmem has other values. You could put a process's u region in one; perhaps its proc table entry (or the system-wide table) in another; the inode table in another; kernel statistics in yet another. You could make essentially one driver with many entry points for the various tables (e.g. different offsets and ranges). The big win is that you could let anyone read some of them, even if you don't want everyone to be able to read /dev/kmem as a whole. Plus, you don't need the silly namelist information any longer either. --- The reason for a separate table is that basically the unix kernel has a handle on files and devices by i-number, not by pathname. You will need to keep this information somwhere. The table is used by mount and umount of course and also some versions of df and perhaps some other system info programs.