Re: why does udev-167 break /lib64/udev/firmware ?

[Jason Vas Dias <jason.vas.dias@gmail.com>]

On Thursday 14 April 2011 18:13:09 Kay Sievers wrote:
> On Thu, Apr 14, 2011 at 18:53, Jason Vas Dias <jason.vas.dias@gmail.com> wrote:
> >   I upgraded to the gentoo version of udev-167 today and found that my wireless interface ( a b43 )
> >   was disabled,  that I only now ( a few hours later ) now found was because /lib64/udev/firmware
> >   seems to be thoroughly broken (and somehow the gentoo's firmware loading rules usually in
> >   /etc/udev/rules.d/50_firmware had disappeared - maybe because they couldn't get this program
> >   to work either ? )
> >
> >   Having cobbled together a new /etc/udev/rules.d/50_firmware :
> >
> >   SUBSYSTEM="firmware", ACTION="add", RUN+="/lib64/udev/firmware"
> >
> >   "firmware" simply emits some error message the first line of which contains "libusb: main.c:"
> >   for valid arguments and does nothing .  I double, triple-checked that the correct "FIRMWARE_PATH"
> >   is generated during config .
> >
> >   But the whole idea of using some complicated libusb internal function,  or even any new executable program,
> >   is incomprehensible to me - to implement these few lines of shell script , which I ended up having to write,
> >   because udev's complicated libusb method failed - so I'm posting here in the hope that udev will see sense
> >   and give us a working firmware script instead of some broken libusb using executable, and to help anyone
> >   else caught by the same issue:
> >
> >   to fix, as root:
> >   #  mv /lib64/udev/firmware /lib64/udev/firmware.broken
> >   #  cat <<'EOF'
> > #!/bin/bash
> > logger "FIRMWARE: $1 $2"
> > if  ! echo "$1" | egrep -q '^--firmware' ; then
> >   logger "FIRMWARE: bad firmware arg: $1";
> >   exit 1;
> > elif ! echo "$2" | egrep -q '^--devpath' ; then
> >   logger "FIRMWARE: bad  devpath arg: $2";
> >   exit 1;
> > fi
> > firmware=$1
> > firmware=${firmware#--firmware=}
> > devpath=$2
> > devpath=${devpath#--devpath=}
> > if [ ! -f /sys/${devpath}/loading ] ; then
> >   logger "FIRMWARE: no loading: /sys/${devpath}/loading";
> >   exit 1;
> > fi
> > if [ ! -f /sys/${devpath}/data ] ; then
> >   logger "FIRMWARE: no data: /sys/${devpath}/data";
> >   exit 1;
> > fi
> > echo 1 > /sys/${devpath}/loading
> > cp -fp /lib64/firmware/${firmware} /sys/${devpath}/data;
> > status=$?;
> > echo 0 > /sys/${devpath}/loading
> > logger "FIRMWARE: copied /lib64/firmware/$firmware to /sys/${devpath}/loading OK: $status"
> > exit $status;
> > EOF
> >     >> /lib64/udev/firmware; chmod a+rx /lib64/udev/firmware
> 
> There is something seriously broken on your system:
> 
> First, there is no /lib64/udev/ directory for udev ever. Gentoo should
> finally stop doing that nonsense. /lib64 is for shared libs only, the
> application private directory is /lib/udev/ regardless of the
> architecture.
> 
> Also all udev default rules like the firmware loader live in
> /lib/udev/rules.d/, not in /etc/udev/rules.d/. /etc is only for
> admins, not for packages.
> 
> Udev's firmware binary does never link against libusb:
>   $ # ldd /lib/udev/firmware
> 	linux-vdso.so.1 =>  (0x00007fff011ff000)
> 	librt.so.1 => /lib64/librt.so.1 (0x00007fd2e37ea000)
> 	libc.so.6 => /lib64/libc.so.6 (0x00007fd2e347d000)
> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007fd2e3279000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007fd2e3c12000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd2e305c000)
> 
> The udev shipped rules file looks like this:
>   $ cat /lib/udev/rules.d/50-firmware.rules
>   # do not edit this file, it will be overwritten on update
> 
>   # firmware-class requests, copies files into the kernel
>   SUBSYSTEM="firmware", ACTION="add", \
>     RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"
> 
> Seems there is a lot to do to clean up the mess you have on your box.
> That's nothing we can fix here. :)
> 
> > P.S. why doesn't udev use libusb-1.0 ? Rebuilding against libusb-0.1-compat didn't help though.
> 
> That should work fine, and does work here.
> 
> Kay
> 
Hi - sorry, but I disagree with several points made above :

> there is no /lib64/udev/ directory for udev ever
then why does your configure script support the '--with-rootlibdir=/lib64' setting ?

If you intend not to support a different rootlibdir,  then you should enforce that by refusing to install on one -
my system has being running fine for years with no /usr/lib or /lib directories -
I use both elf_x86_64 binaries, which link to /usr/lib64, and elf_i386 binaries,
which link to /lib64 - this is simply done by editing /etc/ld.so.conf and /usr/lib{64,32}/lib{c,pthread}.so 
linker scripts (and by changing the default dynamic-linker for gcc to /lib%{-m32:32}%{!-m32:64}/ld-linux.so.2
in gcc's linux.h / linux64.h header files before building (now on gcc-4.6.0, which passes all tests in test suite).

Either say you do not support any other linux platform than Redhat / Fedora derived ones , or support them .

> Udev's firmware binary does never link against libusb:

but it refuses to build without libusb if '--disable-extras' is not given to configure, and without enabling extras,  you
don't get any firmware loading functionality at all -
I infer that in your opinion,   firmware loading functionality is an optional extra.   
Ever tried to do a network boot over a b43 wireless card without firmware loading enabled ? 
That might show you how "optional" it is.

> /lib/udev/rules.d/, not in /etc/udev/rules.d/. /etc is only for

If you do not support your configure script's  "libexecdir" setting, then why does it provide one ?

I use this configure command line:

  $ ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share \
     --sysconfdir=/etc --localstatedir=/var/lib --prefix=/usr --sysconfdir=/etc --sbindir=/sbin --libdir=/usr/lib64 --with-rootlibdir=/lib64 --libexecdir=/lib64/udev \
     --enable-logging --enable-static --without-selinux --disable-introspection --with-firmware-path=\"/lib64/firmware\"

which does NOT complete unless libusb is installed, and it MUST be libusb-0.1, not libusb-1.0 - why ?

Maybe the libusb message I was seeing was an artefact, but really, why are you using an executable to do a shell script's job ?

Do you expect people to modify udevd to load /lib/udev/firmware with GDB to diagnose firmware loading problems ?

I only installed the gentoo portage version of udev because the problem arose with the vanilla build - and
there were still a few old gentoo udev scripts lying around, such as /etc/udev/rules.d/50_firmware that got removed .

RE:
>   # firmware-class requests, copies files into the kernel
>   SUBSYSTEM="firmware", ACTION="add", \
>     RUN+="firmware --firmware=$env{FIRMWARE} --devpath=$env{DEVPATH}"

Thanks for the correct 50_firmware file settings, but they make no difference  - if udevd runs /lib64/udev/firmware executable, firmware fails to load and the system hangs 
for @ 5 minutes .

I guess we just must be from different planets of programming - I cannot understand why this /lib64/udev/firmware executable is required to do the job of a shell script
of a few lines.

Thanks & all the best,
Jason