firmware discussion

[Sepherosa Ziehau]

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
>>
>
>



-- 
Tomorrow Will Never Die