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 <sucan...@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" <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 >> > > -- Tomorrow Will Never Die
