<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Now I see that I had some misunderstanding of a sysctl and tunable
    concepts.<br>
    <br>
    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()).<br>
    <br>
    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).<br>
    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.<br>
    <br>
    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.<br>
    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.<br>
    <br>
    Jan<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 11.05.2017 21:56, Jan Sucan wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:58dec5ff-569b-dc24-69ff-80b915dea0d5@fit.cvut.cz">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      Hello Vasily,<br>
      <br>
      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<em style="font-weight: bold; font-style: normal;
        color: rgb(106, 106, 106); font-family: arial, sans-serif;
        font-size: small; font-variant-ligatures: normal;
        font-variant-caps: normal; letter-spacing: normal; orphans: 2;
        text-align: left; text-indent: 0px; text-transform: none;
        white-space: normal; widows: 2; word-spacing: 0px;
        -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
        255); text-decoration-style: initial; text-decoration-color:
        initial;">'</em>t know how to do correctly yet, but probably it
      will be better to discuss these on IRC.<br>
      <br>
      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).<br>
      <br>
      I think that bootloader doesn<em style="font-weight: bold;
        font-style: normal; color: rgb(106, 106, 106); font-family:
        arial, sans-serif; font-size: small; font-variant-ligatures:
        normal; font-variant-caps: normal; letter-spacing: normal;
        orphans: 2; text-align: left; text-indent: 0px; text-transform:
        none; white-space: normal; widows: 2; word-spacing: 0px;
        -webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
        255); text-decoration-style: initial; text-decoration-color:
        initial;">'</em>t need to be involved. Also the device driver
      code doesn<em style="font-weight: bold; font-style: normal; color:
        rgb(106, 106, 106); font-family: arial, sans-serif; font-size:
        small; font-variant-ligatures: normal; font-variant-caps:
        normal; letter-spacing: normal; orphans: 2; text-align: left;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;
        background-color: rgb(255, 255, 255); text-decoration-style:
        initial; text-decoration-color: initial;">'</em>t need to be
      changed.<br>
      <br>
      Best regards<br>
      Jan<br>
      <br>
      PS: Vasily, I forgot to CC the mailing list ...<br>
      <br>
      <br>
      <div class="moz-cite-prefix">On 07.05.2017 18:03, Vasily Postnicov
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CADnZ6BnYOzxFm6k_usSR+-SZhxqQ+M+SVkvu8Kag0uVhghTgbA@mail.gmail.com">
        <div dir="auto">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?</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">7 мая 2017 г. 18:00 пользователь "Ján
            Sučan" <<a href="mailto:sucanjan@fit.cvut.cz"
              moz-do-not-send="true">sucanjan@fit.cvut.cz</a>>
            написал:<br type="attribution">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello to
              all,<br>
              <br>
              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.<br>
              <br>
              I would like to work on modifying firmware framework for
              loading files from userland.<br>
              <br>
              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().<br>
              <br>
              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.<br>
              <br>
              I would like to ask for your opinions and suggestions.<br>
              <br>
              Thanks,<br>
              Jan<br>
              <br>
            </blockquote>
          </div>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>