Date: Wed, 11 Mar 1998 17:04:51 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Eivind Eklund <eivind@yes.no>, hackers@FreeBSD.ORG Subject: Re: userconfig data -> linker set -> ELF segment Message-ID: <19980311170451.42882@hydrogen.nike.efn.org> In-Reply-To: <199803111530.IAA13420@pluto.plutotech.com>; from Justin T. Gibbs on Wed, Mar 11, 1998 at 08:27:13AM -0700 References: <19980311162228.43166@follo.net> <199803111530.IAA13420@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Justin T. Gibbs scribbled this message on Mar 11: > > * Loading 'just the probe code' isn't possible using a.out > > (AFAIK) > > * Depending on device drivers being LKMs lowers reliability (N > > files that can fail, instead of just having a single kernel) > > Then provide a mechanism to have the driver entry point also called when > linked statically. In a complete LKM solution, you should be able to > load LKMs from a floppy for recovery or to add vendor supplied, binary > only, modules during install. I was thinking about working on a three stage boot that would support this... along with this would allow us to dump the current kernel's main, and replace it with code that handles loading the modules... this has the benifit of removing the SYSINIT code from two different locations... > > * The probe is too late - userconfig (presently, at least) run > > before anything is probed - to be able to stop harmful > > probes etc. > > Which is one of the many flaws in our configuration scheme. It shouldn't > be simply "probe" and "attach", but rather "register configuration items", > run userconfig, probe, run userconfig again to set per instance config > settings, perform attach. yep... this is the way it should be... > > * 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 certainly agree, I was just stating how I believe it should really > be done. > > >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. > > > >> Linker sets are a pain. > > > >Why more so than LKMs? As far as I can tell, LKMs are presently more > >of a pain than linker sets (though LKMs is also a more powerful > >enabling technology). > > Because linker sets provide yet another stumbling block to providing > good LKM support and I feel that real LKM support should be our goal. no, linker sets work fine with kld... it's just that no one spent the time to get linker sets working fine with LKM's... I'm not using linker sets in my bus/device code just because I want to definately know when a driver arrives, not to stuble upon it when I reprobe or anything... pretty much all of this configuration talk will be covered by the new bus/device code that I'm working on... even though Terry likes to show off elf... there has yet to be anyone to actually write an elf module for the kld code... right now, the only executable format that transparent to loading and unloading is a.out and not elf... so until someone actually fixes elf to have all the features that a.out has, it's not that great of a solution... I did come across some more diskspace, so I'm planning on committing my VFS changes in a week or so... this is the second warning... and if I don't get any objections, it's the last... -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for 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?19980311170451.42882>