Date: Wed, 11 Mar 1998 17:01:07 +0100 From: Eivind Eklund <eivind@yes.no> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: hackers@FreeBSD.ORG Subject: Re: userconfig data -> linker set -> ELF segment Message-ID: <19980311170107.44621@follo.net> 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
On Wed, Mar 11, 1998 at 08:27:13AM -0700, Justin T. Gibbs wrote: > > * 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. This sound like the following would be about right: for device in (static set of devices) find driver for in (linker set of drivers) call driver callback with info on device endfor show userconfig with devices registered by register_device #ifdef REALLY_CORRECT_SYSTEM_NOT_YET for each bus call probes endfor show userconfig again for each bus call attach endfor #else for each bus call probes call attach endfor #endif driver callback: call register_device for device, with suitable description etc. For the LKM case, the load-function would call register_device, and (possibly) force a re-probe. Does that sound right to you? The above actually sounds like it might be something that is reasonably quick to implement, and it would both solve my problem (creating an enabling technology for externally developed drivers in a fairly short time horizont) and be an enabling technology for further development (good handling of LKMs with a longer time horizon.) Only tradeoff: Old device drivers/LKMs Will Not Work, as they don't register themselves properly. This might be solvable (e.g, by scanning the present linker sets). Eivind. 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?19980311170107.44621>