Date: Mon, 17 Feb 1997 11:52:56 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-current@freefall.freebsd.org Subject: Re: revision diffs Message-ID: <199702171852.LAA09444@phaeton.artisoft.com> In-Reply-To: <Mutt.19970217011811.j@uriah.heep.sax.de> from "J Wunsch" at Feb 17, 97 01:18:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I posted this morning about a problem with df and mount, but I didn't see > > it show up (to current). Did anyone else see that ? > > Yes, yes! :-) > > It seems only very few people are running 3.0-current, after John has > scared them all off. ;-) This particular problem has been reported at > least three times, but nobody so far stepped forward to post a fix, > nor did anybody with commit power commit a fix either... > > ISTR that Chuck Robey's on the list of committers, hint, hint... :-] The fix is to change the mount arguments to by value rather than by reference (make "data" an arglist pointer instead of a caddr_t), and change out the use of manifest constants in the call (make "type" a const char * instead of an int). The "mount" command should break out the ffs mounting, just like the other FS's. There should be a /sbin/fs directory, and the type specific mounts should go there. The mount command should reference the right one using the "-T" argument (if it even cares any more; the varradic argument passing should allow paramter recognition in the kernel, if necessary, and all FS's could use common code for this). The mounts themselves should return non-fatal failures for unrecognized FS types for root. This would allow iteratively going through FS types known to the kernel at boot time to say "can you mount this?". This would be *very* useful for "umsdosfs" type functionality. This implies an interface for VFS_CANMOUNT() or something similar, if the recognition code is split from the mount code. The implication here is that mounts can all share the same code for NFS export recognition and for vnode overlay (currently, we duplicate code in every FS. I guess we are just stupid). The proc root for chroot should be initialized to be the vnode for the root fs (instead of using a "magic cookie" of NULL to determine this -- it will also simplify and speed up code several places, like in namei()). Finally, the mount list should be seperate from the vnode covering list, such that there is no distinction at the FS layer between root and non-root mount, further simplifying the per FS mount/root mount code, and cleaning up a number of code inheritance errors in LFS and other FS's which are unable to act as root FS's because the duplicate code has not been duplicated for them. Could someone with commit priviledges take care of this for us? Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702171852.LAA09444>