Date: Wed, 11 Mar 1998 18:54:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: userconfig data -> linker set -> ELF segment Message-ID: <199803111854.LAA27983@usr08.primenet.com> In-Reply-To: <199803111444.HAA10346@narnia.plutotech.com> from "Justin T. Gibbs" at Mar 11, 98 07:44:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803111854.LAA27983>