Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

Brian Gerst
2005-04-05T21:29:05Z

Jeff Garzik wrote:
> Brian Gerst wrote:
>
>> Jeff Garzik wrote:
>>
>>> Josselin Mouette wrote:
>>>
>>>> Finally, you shouldn't forget that, technically speaking, using hotplug
>>>> for uploading the firmware is much more flexible and elegant than
>>>> including it in the kernel. Upgrading the firmware and the module
>>>> should
>>>> be two independent operations. People who are advocating the current
>>>> situation are refusing technical improvements just because they are
>>>> brought by people they find convenient to call "zealots".
>>>
>>>
>>>
>>>
>>> This is highly amusing, coming from someone who does not maintain a
>>> driver with a firmware.
>>>
>>> The current firmware infrastructure is too primitive. Compiling the
>>> firmware into the driver is much easier on the driver maintainers and
>>> users, presently.
>>>
>>> Repeating myself,
>>>
>>> * Most firmwares are a -collection- of images and data. The firmware
>>> infrastructure should load an -archive- of firmwares and associated
>>> data values.
>>
>>
>>
>> The firmware interface should only be concerned with getting the blob
>> of data into kernel space. Once it is in kernel space the driver can
>> parse out whatever archive format it is in. Take for example the ihex
>> code that was posted recently. Similar code could be written to parse
>> out a tarball, cpio archive, etc.
>
>
> The archive format for firmware data collections must be standardized,
> and generic code for loading such collections needs to be written, not
> duplicated into each driver.

I never said code shouldn't be standardized or shared. I just said that
it is a seperate function from the process of transferring the data from
userspace to kernel space. That said, initramfs already uses cpio, so
that would be a good choice to use.

--
Brian Gerst