Date: Wed, 26 Jul 95 13:06:14 MDT From: terry@cs.weber.edu (Terry Lambert) To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: freebsd-current@freebsd.org Subject: Re: what's going on here? (NFSv3 problem?) Message-ID: <9507261906.AA22866@cs.weber.edu> In-Reply-To: <9507261340.AA08157@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 26, 95 09:40:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Tue, 25 Jul 95 15:05:57 MDT, terry@cs.weber.edu (Terry Lambert) said: > > > I have some mount system call changes to get rid of the manifest constants > > for file system types, and some user space utilites to clean up to > > handle those changes, next. > > This will, of course, use the defined getvfsbyname() interface, right? Yes. It will also replace the user space mount utility and other per file system utilties with a file system independent and a file system dependent piece. I was thinking of /sbin/fs/<fsname>/<utility name> for the per file system utilities. The agregate of the changes will be such that by adding a kernel module and a directory to /sbin/fs/, you will have a new file system type available without changing, for instance, the enumerated type fields in sys/mount.h. Clearly, I don't have modified mount code yet -- or at least not that is suitable for patches. The intent here is to modularize the installable filesystem interface. The patches (which I have promised to upload today) to do away with XXX_mountroot frobs should mean that any new file system type which exists in the kernel at the time root is to be mounted can be used as a root file system. I expect to have to use this for OSF/1 UFS and AIX JFS. I haven't hacked on the NFS code, and some of the CD9660 code is actually very broken, IMO, so I haven't fully modified kern/init_main.c or i386/i386/autoconf.c to remove the per FS type frobbing which is being done there. I figure that code cleanup will have to wait until it has been pounded out a bit. The CD9660 code is unhappy because it screws around with options on the mount rather than the mount auto-detecting format (the Sun HFS support is the only one that's really self-imposing). The MSDOSFS root mount code isn't entirely broken, unless you consider the MSDOSFS code itself to be broken (which it is), so I'm torn between hacking it out and saving the DOSFS root mount code until someone can do a decent long name support mechanism, hopefully ala Windows95. I have added a vfs_mountroot routine to kern/vfs_conf.c that takes as its argument a pointer to the FS specific vfsops vector. I was in vfs_init.c the other day, and it is pretty obvious where the Heidemann code was pounded on to jam it into the BSD mountable file system paradigm. A cleanup of that code will have to wait until I'm willing to take about a week for it, since it will mean changing the lkm code as well. This would be a change for the better, since it would mean a common interface for file system registration. I really don't want to clean up the pardigm -- the Heidemann code *says* that it is bogus to supply an opvector without supplying an entry vector, but I'm not totoally sure I agree with that. For instance, there should probably be a disction between block and directory management code and the bottom end of FFS wants to be unaware of the system interface as much as possible... to the point of being able to be stacked on something other than UFS, in fact. That's really only a possible future direction for the code. Some of the use of linker set code is garbage and really ought to go. The set assembly is predicated on the existance of a manifest constant being declared (ie: "MFS"), and so is just as suitably done using the manifest constant instead. Or the manifest constant should go (the mountroot work means that the problem is really being tackled from both ends). While on that topic, didn't anyone notice that the PCI code is the only code that actually uses the linker set length field? Everything else looks for the NULL record at the end of the set. Does anyone want to clean up the PCI code to do the same, and get rid of the length field altogether? More later, Terry Lambert terry@cs.weber.edu --- 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?9507261906.AA22866>