> > 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, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
