firmware discussion

[Jan Sucan]

Hello sephe,

thank you for the question. I am thinking of keeping a part of the old 
functionality. Firmware for those devices could be compiled into the 
kernel (by default).

I think, this concerns only the isp driver for Qlogic based SCSI and 
FibreChannel SCSI Host Adapters.

Could you please point me to other drivers, which will need the same 
treatment?
I am afraid I could have overlook some of them.

Thanks
jan


On 26.05.2017 03:13, Sepherosa Ziehau wrote:
> Hi,
>
> I am looking at your recent work about the firmware KPIs.  I have one
> question about moving firmware to userland: some kernel drivers will
> need to load the firmware at device_attach time, i.e. before / is
> mounted, what's your plan to address that?
>
> Thanks,
> sephe
>
>
> On Fri, May 12, 2017 at 4:58 PM, Jan Sucan <sucanjan at fit.cvut.cz> wrote:
>> Now I see that I had some misunderstanding of a sysctl and tunable concepts.
>>
>> Currently, when a firmware is embedded in kernel modules, there are some
>> information embedded inside too. That is info about firmware license, which
>> user must accept by setting the corresponding tunable in order for the
>> firmware to be registered, and info about a parent firmware (multiple images
>> in one kernel module which are accessible through multiple successive calls
>> of firmware_get()).
>>
>> If firmware images are moved from kernel modules to userland, these
>> information must be kept somewhere else. I think of two possibilities: 1)
>> sysctl/tunable 2) config file (e.g. /etc/firmwares).
>> There should be stored five pieces of info for each firmware image: if
>> license ack is needed, image name, version, path to a firmware binary and a
>> parent image name.
>>
>> But I think, that the parent image (multiple images in one kernel module)
>> concept have no use and can be safely removed. I have searched through the
>> kernel code, and I did not find any use of that. It would simplify the
>> current code and also the future code. If it is removed, there will be no
>> need for taking care of order of the configuration processing in order to
>> resolve parent references properly.
>> Now, the correct order is ensured statically by the order of arguments for
>> the sys/tools/fw_stub.awk script which is used to generate C code of
>> firmware kernel modules.
>>
>> Jan
>>
>>
>>
>> On 11.05.2017 21:56, Jan Sucan wrote:
>>
>> Hello Vasily,
>>
>> I would like to put the code for a review after it is much closer to some
>> production quality (said by a kernel newbie :-) ). The purpose of the code I
>> mentioned is for me to get my hands on DragonFly BSD kernel for the first
>> time. And there are some things which I don't know how to do correctly yet,
>> but probably it will be better to discuss these on IRC.
>>
>> I used fp_open() and friends as Matthew Dillon suggested back then in the
>> original "firmware discussion" (see the Kernel Archives from March to May
>> 2010).
>>
>> I think that bootloader doesn't need to be involved. Also the device driver
>> code doesn't need to be changed.
>>
>> Best regards
>> Jan
>>
>> PS: Vasily, I forgot to CC the mailing list ...
>>
>>
>> On 07.05.2017 18:03, Vasily Postnicov wrote:
>>
>> Hello, Jan. Can't find the code, can you point me to it? Btw., why accessing
>> files from kernel with open/read/write/etc-like API is considered a bad
>> practice? Will bootloader also support this new functionality?
>>
>> 7 мая 2017 г. 18:00 пользователь "Ján Sučan" <sucanjan at fit.cvut.cz> написал:
>>> Hello to all,
>>>
>>> I would like to introduce myself. My name is Jan Sucan. I am from Slovakia
>>> and I study in Prague. I have done some simpler embedded systems programming
>>> in the past and I am very interested in kernel-level programming.
>>>
>>> I would like to work on modifying firmware framework for loading files
>>> from userland.
>>>
>>> I have added experimental support to subr_firmware.c for reading a
>>> firmware data using fp_open() from userland and registering it with
>>> firmware_register().
>>>
>>> I think of implementing a mapping of firmware names to file paths using
>>> sysctl, as Johannes Hofmann suggested back then in May 2010. This mapping
>>> would take precedence over loading the firmware modules, so transition to
>>> the new way of loading firmware data could be gradual.
>>>
>>> I would like to ask for your opinions and suggestions.
>>>
>>> Thanks,
>>> Jan
>>>
>>
>
>