sucanjan at fit.cvut.cz
Fri May 12 01:58:22 PDT 2017
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.
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
> 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
>> 7 мая 2017 г. 18:00 пользователь "Ján Sučan" <sucanjan at fit.cvut.cz
>> <mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernel