From owner-freebsd-hackers Wed Mar 11 11:27:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13517 for freebsd-hackers-outgoing; Wed, 11 Mar 1998 11:27:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA13446 for ; Wed, 11 Mar 1998 11:27:03 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id MAA15061; Wed, 11 Mar 1998 12:27:02 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd014986; Wed Mar 11 12:26:47 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id MAA00112; Wed, 11 Mar 1998 12:26:44 -0700 (MST) From: Terry Lambert Message-Id: <199803111926.MAA00112@usr08.primenet.com> Subject: Re: userconfig data -> linker set -> ELF segment To: eivind@yes.no (Eivind Eklund) Date: Wed, 11 Mar 1998 19:26:44 +0000 (GMT) Cc: gibbs@narnia.plutotech.com, hackers@FreeBSD.ORG In-Reply-To: <19980311162228.43166@follo.net> from "Eivind Eklund" at Mar 11, 98 04:22:28 pm 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 > 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