Summary of responses to /etc/mnttab question

[silver at csu-cs.UUCP]

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.