Date: Wed, 2 Aug 95 18:37:11 MDT From: terry@cs.weber.edu (Terry Lambert) To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: questions@freebsd.org Subject: Re: Loadable kernel modules/filesystems Message-ID: <9508030037.AA24090@cs.weber.edu> In-Reply-To: <9508021920.AA19166@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Aug 2, 95 03:20:45 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> I do not believe that there is any valid reason to do this, which is > >> why I didn't implement it that way. > > > So i can add frogfs to the kernel and mount a frogfs file system without > > having to recompile my kernel or modify system header files. > > Right, you can indeed do that now. No, I can't. The vfssw and vfsconf arrays in kern/vfs_init.c are limited to MOUNT_MAXTYPE + 1 entries, and this + 1 entry is there soley to tag the end of the list for vfsinit() in the same file. The use of MOUNT_MAXTYPE+1 in fs_sysctl() in the same file is really broken. In _lkm_vfs() in kern/kern_lkm.c, the index is expected to be specified. If the index passed in is -1 with the module, meaning allocate an unused slot, the module loader traverses from the end of the list (minus one -- MOUNT_MAXTYPE bogosity again) and allocates one of the "unused" slots. Unused, that is, unless you are using all the known file system types. Even if you aren't, it bogusly causes the the mount command for the file system type used to provide bogus arguments to the stolen slot, and in fact, prevents future loading of the supported file system type whose slot was stolen. I won't even get into what happens with the pointer dereference on multiple type-specific vnodeops entries, except to say that only the first is handled correctly, the way that the vfs_opv_init() function is being called in the load. So if I have a limited implementation, am not using a file system type near the end of the table and don't plan on using a file system type between the end of the table and the point I want allocated, then it *is* possible to do this in a kinda half-assed way. Of course, the code is the only documentation for this information. This is all vastly inferior to not having a slot index/file system type correlation at all... which even if the number of slots was left alone, my allocation of a slot for a new file system type would neither screw an existing-but-not-loaded file system out of its slot when the time cane to use it, nor leave potentially confusing mount_XXX mount commands able to make the mount() call but unable to actually perform the mout for the FS in question. > >> > Really, it wants file systems to be described with a flags descriptor > >> > so that you can know whether a file system is local or remote > >> > >> Which we have and do set as appropriate. > > > Prior to root mount, and in all cases? > > Yes. It's in the vfsconf structure's `flags' field; the flag is > called VFCF_NETWORK. There are also flags for statically-loaded > filesystems (VFCF_STATIC), read-only filesystems (VFCF_READONLY), > synthetic filesystems with no physical backing like procfs and kernfs > (VFCF_SYNTHETIC), and loopbacks (VFCF_LOOPBACK). Ah. I see it in the VFS_SET() stuff now. Never mind. It could be a bit more appropriately located. I could decide a file system is not local at mount time. For instance, a union mount of a read only network volume and a local disk for compilation of source should flag the mount as VFCF_NETWORK by way of inheritance. Probably this wants to be a flag in the mount structure that is inherited from the file system type(s) being mounted, potentiall as multiple mounts being represented as a union. 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?9508030037.AA24090>