Date: Wed, 11 Mar 1998 19:26:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: gibbs@narnia.plutotech.com, hackers@FreeBSD.ORG Subject: Re: userconfig data -> linker set -> ELF segment Message-ID: <199803111926.MAA00112@usr08.primenet.com> In-Reply-To: <19980311162228.43166@follo.net> from "Eivind Eklund" at Mar 11, 98 04:22:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This is not feasible at present. There are several reasons: > > * The PCI LKM code in -current doesn't work Well, before you embark on a grand brick building, lets make sure the bricks are there and that the foundation is laid. > * Loading 'just the probe code' isn't possible using a.out > (AFAIK) A nice migration mechanism at this point would be to depend on ELF kernel modules, but an a.out kernel. That said, you can do it using the "extras" section. The "extras" is a header that follows the code/data that's "supposed to be there" according to the a.out information. You know how big it is by looking at the length of the file and subtracting out what's supposed to be there. It's a crutch for not having ELF, really. > * Depending on device drivers being LKMs lowers reliability (N > files that can fail, instead of just having a single kernel) I think it raises it. If I get a failure in my sound driver, my system still boots. 8-). > * The probe is too late - userconfig (presently, at least) run > before anything is probed - to be able to stop harmful > probes etc. Harmful probes are (or should be) a non-PNP ISA card problem, only. One way around this is to have "discardable" ELF sections. Leave the visual config code, etc., in the kernel for boot, but then discard (and reclaim the memory used by) the configurator when you are done with configuring. > * It is more work than I can chew, and thus won't be done as > part of the minor set of changes I wanted to do. I think that there needs to be a coherent plan to use ELF section attribution. With the importation of the ELF tools, FreeBSD is now in a position where it could rely on ELF for kernel modules, even for a.out kernels. This not a bad thing; the ELF kernel module problem has to be solved anyway. > I was only planning to make userconfig data a linker set, and change > config to (also) scan sys/conf/*/files.extra and > sys/conf/*/options.extra, as an enabling technology for externally > developed kernel parts. This is the sort of thing that will be hard to replace because it will work "well enough". 8-(. 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?199803111926.MAA00112>