From owner-freebsd-hackers Wed Mar 11 10:55:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA05557 for freebsd-hackers-outgoing; Wed, 11 Mar 1998 10:55:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA05507 for ; Wed, 11 Mar 1998 10:55:01 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id LAA02785; Wed, 11 Mar 1998 11:54:56 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd002748; Wed Mar 11 11:54:52 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id LAA27983; Wed, 11 Mar 1998 11:54:46 -0700 (MST) From: Terry Lambert Message-Id: <199803111854.LAA27983@usr08.primenet.com> Subject: Re: userconfig data -> linker set -> ELF segment To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Wed, 11 Mar 1998 18:54:46 +0000 (GMT) Cc: mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199803111444.HAA10346@narnia.plutotech.com> from "Justin T. Gibbs" at Mar 11, 98 07:44:27 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> The problem is that you need to be able to agregate linker sets > >> at run time, not at link time. > > > > You're making things too difficult. 8) > > Exactly. Don't use a linker set at all. Convert all drivers to > LKMs, load they "probe" section of all LKMs, have an entry point > in the probe section register the driver with userconfig. > > Linker sets are a pain. If you don't care about it working with a.out, use section attribution. I don't know how to select a section name in gcc; it may be with the same #pragma's a Visual C++, given that there is a gcc that compiles WIN32 code. Kernel loader (boot blocks): load normal code sections load normal data sections seperately load "init" (or whatever) sections provide an interface for the kernel to iterate the sections loaded kernel iterates config sections kernel registers a configuration with a configurator from: (A) self (B) config section references KLD loader (loadable kernel modules) load normal code sections load normal data sections seperately load "init" (or whatever) sections directlyly invoke the same registration mechanism, per above User config (unloadable kernel modules) identify config section for module to be removed deregister it free its memory This last implies that the code section, data section, and "init" section are sperated in the kernel for devices which can be unloaded. Adding a driver to the default kernel can be done with an ELF image archiver that can paste its sections onto the end, or not. This presumes the code is PIC. Userconfig for adding a driver: KLD the driver archive it's sections into the kernel so it will be there on the next reboot Userconfig for deleting a driver: unload the module archive it's sections out of the kernel so it won't be there on the next reboot If we had a (mythical) third stage boot, we could agregate ELF sections in memory *much* more easily. You would assemble an index as you loaded each file in the /kern/modules directory, making it available to the kernel. Everything that could be seperate would be, even if it were boot-critical, since the boot blocks would be seperable. Hardware that wasn'r probed present would have its module unloaded. Hardware that would be present, but the user foolishly wants, for some reason, to not load the associated module -- well, the user can move the module to /kern/modules/inactive. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message