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

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

[Jason Vas Dias]

Hi - 
 
   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


P.S. why doesn't udev use libusb-1.0 ? Rebuilding against libusb-0.1-compat didn't help though.

Sorry, new to this list - please reply to : jason.vas.dias@gmail.com

All the best,
Jason.

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

[Kay Sievers]

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

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

[Jason Vas Dias]

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

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

[Jason Vas Dias]

corrections - a couple of typos in previous mails:
> I use both elf_x86_64 binaries, which link to /usr/lib64, and elf_i386 binaries,
> which link to /lib64
                           ^- should be '32'

Final scriptlet:

#!/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
cat /lib64/firmware/${firmware} > /sys/${devpath}/data;
# ^-- not 'cp -fp', though this works too
status=$?;
echo 0 > /sys/${devpath}/loading
logger "FIRMWARE: copied /lib64/firmware/$firmware to /sys/${devpath}/loading OK: $status"
exit $status;
#

That libusb message arose when this script was just :
/lib64/udev/firmware.bin "$1" "$2" >/tmp/FW 2>&1;
status=$?;
logger "FIRMWARE STATUS: $status  -  $(cat /tmp/FW) - LOADING : $(ls -l /sys/devices/pci0000:00/0000:00:06.0/0000:30:00.0/ssb0:0/firmware/ssb0:0/loading)";
rm -f /tmp/FW || : ; 

The first time udev calls this with the correct udev arguments, the first line of a message containing the text "libusb main.c:"  is emitted. 
Then it is called once every 10 seconds or so with NO arguments for around 5 minutes because the binary executable fails .

That's OK, I've submitted a patch to remove the firmware binary and replace with the above script on all udev builds on my system -
I just thought I should let you know and potentially help others with the same issue .

Thanks & Regards,
Jason

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

[Kay Sievers]

On Thu, Apr 14, 2011 at 21:03, Jason Vas Dias <jason.vas.dias@gmail.com> wrote:
> 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.

> 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 ?

_My_ script supports everything, but _your_ options are broken. Nobody
prevents --libdir=/tmp if you like to do that too. :)

> 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 .

Nonsense. "Application directories" are not arch specific, and do not
belong into that dir. It's nothing about Red Hat or anybody else, it's
just some total nonsense Gentoo is doing. Maybe you should have a
/usr64/ and /etc64 too. :)

>> 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 ?

It does. Udev supports and needs both. Please read the man page why.

> 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 ?

Because it's a different API and I don't care to convert rather exotic
tools I personally don't use. Nothing in core udev uses it.

> 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 ?

Because we need to encode filenames in that binary.

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

No, I expect them to configure and install udev correctly and it will
work out-of-the-box, like for everybody else for years. :)

> 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 .

Such file was never part of udev. Not sure what you install on your system.

> 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.

Good luck,
Kay

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

[Jason Vas Dias]

On Thursday 14 April 2011 22:26:58 Kay Sievers wrote:
> > 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 ?
> 
> Because we need to encode filenames in that binary.
> 
ever heard of cpio ? the kernel understands that.
Why do you need to encode filenames ? surely /sys/devices/.../ etc is "trusted" ? 
In what way are filenames encoded ? or do you mean "encrypted" - why ? 
b43 / ssb / /usr/src/linux/drivers/base/firmware_class.c doesn't seem to mention "encoded" or "encrypted" filenames
and seem to work fine without any filenames being sent ?  Why isn't this "filename encoding" interface to 
drivers/base/class/firmware* documented anywhere ?

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

[Kay Sievers]

On Fri, Apr 15, 2011 at 00:56, Jason Vas Dias <jason.vas.dias@gmail.com> wrote:
> On Thursday 14 April 2011 22:26:58 Kay Sievers wrote:
>> > 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 ?
>>
>> Because we need to encode filenames in that binary.
>>
> ever heard of cpio ? the kernel understands that.

Ever heard of reading source code, before asking needless questions?

Kay

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

[Matthias Schwarzott]

On Donnerstag, 14. April 2011, Kay Sievers wrote:
> 
> 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.

The ebuild did install to /lib64/udev, correct. But there was always the 
assumption that /lib linked to /lib64 in these cases, so that /lib/udev always 
is valid.
But it seems I was wrong, so that will get changed back to plain "/lib/udev" I 
think.

Matthias