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" <sucan...@fit.cvut.cz
<mailto:sucan...@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
