From owner-freebsd-hackers Wed Apr 30 13:36:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA16665 for hackers-outgoing; Wed, 30 Apr 1997 13:36:58 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA16632 for ; Wed, 30 Apr 1997 13:36:52 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id MAA07052 for ; Wed, 30 Apr 1997 12:03:50 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA02524; Wed, 30 Apr 1997 12:02:04 -0700 From: Terry Lambert Message-Id: <199704301902.MAA02524@phaeton.artisoft.com> Subject: Re: Unloading LKMs (was Re: A Desparate Plea for Help...) To: rminnich@Sarnoff.COM (Ron G. Minnich) Date: Wed, 30 Apr 1997 12:02:04 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "Ron G. Minnich" at Apr 30, 97 11:02:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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.