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.
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.
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.
> There seems to be a number of ways to approach this from within -current, so I
> thought I'd ask-
>
> While I'm configuring a PCI driver, I want to refer to another (possibly
> loadable) module- I can name it anything I want. It doesn't have any standard
> entry points- basically, it's a container for firmware for my card that I want
> to refer to when I'm configuring the PCI driver, and then I can release (and
> the module can go away after that).
>
> If this was Solaris, I would use weak elf binding and some (undocumented) DDI
> functions to get the kernel linker to pull in the module and satisfy the
> reference at runtime.
>
> What's the right mechanism currently for doing this in FreeBSD-current? A
> couple of pointers in the right direction would be greatly appreciated.
>
> -matt
>
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
\\ 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
