Date: Wed, 14 Jun 2000 14:27:12 -0700 From: Mike Smith <msmith@freebsd.org> To: mjacob@feral.com Cc: hackers@freebsd.org Subject: Re: loading modules from within the kernel.... Message-ID: <200006142127.OAA00558@mass.cdrom.com> In-Reply-To: Your message of "Wed, 14 Jun 2000 14:13:39 PDT." <Pine.BSF.4.05.10006141411230.4094-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Since your driver initialisation is going to (often) happen before disk > > I/O, I'd be inclined to put a dependancy in your module to another module > > with a container object containing the firmware. > > Right. I would expect that the loader(8) would DTRT. Of course, this then > raises an issue about how this might be supported statically as well! I keep running up against the need for dlsym() functionality in the kernel; eg. the work I'm doing with the Mylex and AMI drivers is going to mandate CAM, even if you don't have any other SCSI hardware. > > Of course, this brings to light the fact that I don't think we support > > "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. > > Oh, err, uh, that's gotta be fixed. Let the caller/invoker of a load action > decide what the policy for failure is. The problem here is that we depend on the loader to perform early loads for stuff in the boot path, and that's where you are. Realistically, the "right" way to handle your particular case is probably going to be to associate a pile of PCI IDs with each of your firmware objects, and then use the loader's PCI-awareness to pull them in. > > The current school of thought for solving this would be to have your > > firmware load as a plain container in a fashion similar to the way we > > load the MFS root image, and then use preload_search_by_type() to locate > > it. > > Does this approach use functions/APIs that are likely to not change for a > while? Yes; things like MD_ROOT and the splash screen code depend on being able to preload opaque objects and then look them up. Right now, the API needs to be extended to these objects after bootup. *sigh* So much to do, so little time. Yadda yadda. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?200006142127.OAA00558>