Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

David Lang
2006-08-30T21:18:24Z

On Wed, 30 Aug 2006, Sven Luther wrote:

>> no, at least not in the current kernel. as was mentioned earlier in this
>> thread the ipw2200 needs the firmware at initialization, but some others
>> don't need it until open. I don't know if it's even possible to re-write
>> the driver to do this.
>
> Oh well, this doesn't explain why it is so, but i suppose you know what you
> speak about.

I'm a user, not a developer. I know what is, but not nessasarily why, and I have
no idea how bad it would be to change.

>>> If we want to remove it, then we put, not the module, but the firmware
>>> itself
>>> with some basic userspace to load it on demand in the initramfs, and this
>>> is
>>> reason enough to create an initramfs. The fact that the builtin device is
>>> initialized before the initramfs is loaded seems like a bug to me, since
>>> the
>>> idea of the initramfs (well, one of them at least), was to initialize it
>>> early
>>> enough for this kind of things.
>>
>> this isn't my understanding.
>
> Indeed, in the initrd era, the ramdisk was initialized too late for this kind
> of stuff, but it was one of the features of the initramfs ramdisks to
> initialize it earlier, which made firmware loading possible.
>
>> my understanding is that the kernel fully initializes all built-in drivers,
>> then loads userspace and starts running it.
>
> Well, there is userspace and userspace.
>
>> that userspace can be on a device that it knows how to read, or it can be
>> userspace on initramfs so that you can load additional modules to give you
>> access to the hardware that you want to run on.
>
> Yep, but initramfs is initialized ways earlier than normal userspace.
>
>> however this is not soon enough to supply the firmware for devices like
>> this.
>
> Are you sure of this ? This is somewhat contrary to what i have heard, and it
> sure would make sense to be able to access the initramfs ramdisk much earlier.

I could easily be wrong about this. can someone who really knows weigh in on
this?

>>> If on the other side, it is more important to not have an initramfs
>>> (because
>>> of security issues, or bootloader constraints or what not), then sure,
>>> there
>>> is not much choice than putting the firmware in the driver or in the kernel
>>> directly.
>>>
>>> But again, the initramfs is just a memory space available at the end of the
>>> kernel, and there is no hardware-related constraint to access it which are
>>> in
>>> any way different from having the firmware linked in together with the
>>> kernel,
>>> so it is only a matter of organisation of code, as well as taking a
>>> decision
>>> on the above, and to act accordyingly.
>>
>> if the firmware needed for any drivers compiled in was appended to the
>> kernel the same way that initramfs is, without requireing the other things
>> needed to make initrmfs useable I think that would be reasonable (bundling
>> them togeather as opposed to embedding the firmware in the kernel). it may
>> even be possible to have the firmware as files in a initramfs that contains
>> nothing else, and the kernel knows how to read the data directly (without
>> the hotplug firmware request userspace stuff)
>
> Indeed, and it seems to me that exactly this kind of use was indeed considered
> when the initramfs infrastructure was designed. Not sure about the latest bit
> concerning hotplug though.

this gets back to the question of how early this early userspace is

David Lang