[PATCH] systemd: fix missing path separator in firmware-path

[PATCH] systemd: fix missing path separator in firmware-path

[andreas.kling]

From: Andy Kling <andreas.kling@peiker-cee.de>

udev fails to load firmware for CONFIG_FW_LOADER_USER_HELPER
systemd-udevd[158]: did not find firmware file 'xxx'

function builtin_firmware currently assumes FIRMWARE_PATH ends with "/"
fixing the path passed to meson allows the firmware loader to succeed.
systemd-udevd[145]: writing '/lib/firmware/xxx'

Signed-off-by: Andy Kling <andreas.kling@peiker-cee.de>
---
 meta/recipes-core/systemd/systemd_237.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_237.bb b/meta/recipes-core/systemd/systemd_237.bb
index 3efca33e73..8ff049160b 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -185,7 +185,7 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
                   -Drootlibdir=${rootlibdir} \
                   -Drootprefix=${rootprefix} \
                   -Dsysvrcnd-path=${sysconfdir} \
-                  -Dfirmware-path=${nonarch_base_libdir}/firmware \
+                  -Dfirmware-path=${nonarch_base_libdir}/firmware/ \
                   "
 
 # Hardcode target binary paths to avoid using paths from sysroot
-- 
2.18.0

Re: [PATCH] systemd: fix missing path separator in firmware-path

[ChenQi]

Hi Andreas,

I'm OK with this patch.

I'm interested in your environment. Could you please give me some more 
details about why you need this userspace firmware loading mechanism?

I'm upgrading systemd to 239, and I'm going to remove this option in 239.
The reason is that systemd's minimal kernel requirement is 3.13, and 
userspace firmware loading is needed before kernel 3.7. I just checked 
237, its minimal requirement is also 3.13.

The userspace firmware loading support has been removed from udev for 
several years. It's said that using userspace firmware loading is slow, 
and kernel has been able to do this for a long time.

So could you please give me some details about your environment? Is 
there some compelling reason to use userspace firmware loading 
mechanism? This would help me to check if we should keep local patches 
with more details updated in them.

Best Regards,
Chen Qi



On 07/07/2018 08:28 PM, andreas.kling@gmail.com wrote:
> From: Andy Kling <andreas.kling@peiker-cee.de>
>
> udev fails to load firmware for CONFIG_FW_LOADER_USER_HELPER
> systemd-udevd[158]: did not find firmware file 'xxx'
>
> function builtin_firmware currently assumes FIRMWARE_PATH ends with "/"
> fixing the path passed to meson allows the firmware loader to succeed.
> systemd-udevd[145]: writing '/lib/firmware/xxx'
>
> Signed-off-by: Andy Kling <andreas.kling@peiker-cee.de>
> ---
>   meta/recipes-core/systemd/systemd_237.bb | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd_237.bb b/meta/recipes-core/systemd/systemd_237.bb
> index 3efca33e73..8ff049160b 100644
> --- a/meta/recipes-core/systemd/systemd_237.bb
> +++ b/meta/recipes-core/systemd/systemd_237.bb
> @@ -185,7 +185,7 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
>                     -Drootlibdir=${rootlibdir} \
>                     -Drootprefix=${rootprefix} \
>                     -Dsysvrcnd-path=${sysconfdir} \
> -                  -Dfirmware-path=${nonarch_base_libdir}/firmware \
> +                  -Dfirmware-path=${nonarch_base_libdir}/firmware/ \
>                     "
>   
>   # Hardcode target binary paths to avoid using paths from sysroot

Re: [PATCH] systemd: fix missing path separator in firmware-path

[Andy]

Hi Chen,


Am Mo., 9. Juli 2018 um 05:13 Uhr schrieb ChenQi <Qi.Chen@windriver.com>:
>
> Hi Andreas,
>
> I'm OK with this patch.
>
> I'm interested in your environment. Could you please give me some more
> details about why you need this userspace firmware loading mechanism?
>
> I'm upgrading systemd to 239, and I'm going to remove this option in 239.
> The reason is that systemd's minimal kernel requirement is 3.13, and
> userspace firmware loading is needed before kernel 3.7. I just checked
> 237, its minimal requirement is also 3.13.
>
> The userspace firmware loading support has been removed from udev for
> several years. It's said that using userspace firmware loading is slow,
> and kernel has been able to do this for a long time.
>
> So could you please give me some details about your environment? Is
> there some compelling reason to use userspace firmware loading
> mechanism? This would help me to check if we should keep local patches
> with more details updated in them.
>
> Best Regards,
> Chen Qi
>
>
>
> On 07/07/2018 08:28 PM, andreas.kling@gmail.com wrote:
> > From: Andy Kling <andreas.kling@peiker-cee.de>
> >
> > udev fails to load firmware for CONFIG_FW_LOADER_USER_HELPER
> > systemd-udevd[158]: did not find firmware file 'xxx'
> >
> > function builtin_firmware currently assumes FIRMWARE_PATH ends with "/"
> > fixing the path passed to meson allows the firmware loader to succeed.
> > systemd-udevd[145]: writing '/lib/firmware/xxx'
> >
> > Signed-off-by: Andy Kling <andreas.kling@peiker-cee.de>
> > ---
> >   meta/recipes-core/systemd/systemd_237.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd_237.bb b/meta/recipes-core/systemd/systemd_237.bb
> > index 3efca33e73..8ff049160b 100644
> > --- a/meta/recipes-core/systemd/systemd_237.bb
> > +++ b/meta/recipes-core/systemd/systemd_237.bb
> > @@ -185,7 +185,7 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
> >                     -Drootlibdir=${rootlibdir} \
> >                     -Drootprefix=${rootprefix} \
> >                     -Dsysvrcnd-path=${sysconfdir} \
> > -                  -Dfirmware-path=${nonarch_base_libdir}/firmware \
> > +                  -Dfirmware-path=${nonarch_base_libdir}/firmware/ \
> >                     "
> >
> >   # Hardcode target binary paths to avoid using paths from sysroot
>
>

yes I would wish not to use the user helper, but it is what I get currently.
What are the alternatives? I'm investigating those, unfortunately with
low priority.
- Move everything to modules so it gets loaded after rootfs is mounted
- Builtin firmware into the kernel
- Provide an initramfs with the required bits

I found https://www.kernel.org/doc/html/v4.17/driver-api/firmware/index.html
quite helpful.
User helper is not the common case anymore, udev removed the support
for quite some time now.
So I do not get firmware loaded for builtin modules in an image "out
of the box" without further invest.
What is the common way in yocto today if one has concerns about size,
speed or something?

Kind regards