Date: Wed, 30 Apr 1997 12:02:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: rminnich@Sarnoff.COM (Ron G. Minnich) Cc: hackers@freebsd.org Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) Message-ID: <199704301902.MAA02524@phaeton.artisoft.com> In-Reply-To: <Pine.SUN.3.91.970430105937.819A-100000@terra> from "Ron G. Minnich" at Apr 30, 97 11:02:02 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Actually, it builds tables of functions at link time using linker > > sets. The functions are then used early at runtime to build the > > devsw tables. This implementation was expedient 17 months ago and > > bad 16 months ago. > > I agree on the comment re linker sets. I would like to see these vanish > for a simple reason: try sometime to build a really minimal kernel and it > will fail at link time since there are missing linker sets. ouch. > > By minimal, i mean minus any file systems for example. And yes, I do have > a use for this. Hey! I told you so! I told you so! I have patches for doing exactly this. The problem is that the size of the structures are calculated off a statically linked FFS. The patch address this by making a four line modification to the output of vnode_if.sh (two in each file) and many changes to the mount and vfs_init code. I had exactly this situation, where I loaded the Heidemann framework itself as a dynamically loaded VXD in Win95, and then loaded FS modules, as necessary. The generalization is applicable to the idea of having a hard-coded, non-VFS VFS interface provider for a single boot device (like say a flash card for an embedded system), so it's not Win95 specific, it's a general win. One caveat: you must presort the VOPS at load time to get around the descriptor ordering issues that are otherwise automatic in the statically linked case. You can't use linker sets to glue the code across module boundries. This has the (desirable) side effect of redusing the function call overhead by one push/call/pop series for every VOP call, so it's a general win in any case. You can do the sort in place, if you bubble sort. It's boot code, so it doesn't need to be very optimal. The mount code changes have to do with moving the mount point overlay code into common code, and out of the FS's proper. You have to do this in the flash case (assumes DEVFS and a union mount for a bootable BSD). It save you about 8k per FS type, if you do the NFS export handling code up at the higher level at the same time. 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?199704301902.MAA02524>