Re: udev-067 and 2.6.12?

[Kay Sievers <kay.sievers@vrfy.org>]

On Wed, Aug 17, 2005 at 12:26:11AM +0100, Alistair John Strachan wrote:
> On Tuesday 16 August 2005 23:49, Alistair John Strachan wrote:
> > On Tuesday 16 August 2005 23:33, David Brown wrote:
> > > Check out the release notes for udev 059
> > > I think your problem may be caused by the changes in that release
> > > and you should probably add the code below to your udev rules file
> > > <snip>
> > > RUN+="/sbin/udev_run_devd"
> > > </snip>
> > >
> > > I've noticed this problem as well loading firmware but everything was
> > > fixed when I made the two extra binaries in extras/run_directory and
> > > added the code above to my rules file
> > >
> > > - David Brown
> >
> > (Sorry linux-hotplug-devel, I thought I'd add to CC after Greg's suggestion
> > elsewhere in this thread).
> >
> > Obviously, this fixed it. Thanks a lot for the hint.
> 
> Okay, I've found a few problems with udev 067 so far.
> 
> Greg suggested changing comparisons in the udev rules to = instead of =, 
> which makes sense (comparison versus assignment). There are several files in 
> the etc/udev directory that don't observe this (frugalware/slackware).

Yes, that's good to make the correct assignment. For now only SYMLINKwill reset former assigned values and you need SYMLINK+= and ENV{}= will
assing instead of match. All other keys should still work, but if we
require some more features for a key, we may need to change that in the
future.

> Secondly, the stuff in run_directory doesn't link:
> 
> # make
> cc -DUSE_LOG -O2 -march=k8 -mfpmath=sse -s -pipe -c -o run_directory.o 
> run_directory.c
> ld -s -o udev_run_devd udev_run_devd.o 
> run_directory.o ../../udev.a ../../libsysfs/sysfs.a
> ld: warning: cannot find entry symbol _start; defaulting to 00000000004000f0
> udev_run_devd.o: In function `log_message':
> udev_run_devd.c:(.text+0x9d): undefined reference to `vsyslog'
> udev_run_devd.c:(.text+0xb6): undefined reference to `getenv'
> 
> GCC 4.0.1/binutils 2.16.91.0.2. I worked around it by linking with gcc instead 
> (like the rest of udev does). This worked fine. I didn't compile udev or the 
> run_directory stuff against klibc.

Hmm, no other distro seems to have this problem. Did you overwrite
CFLAGS for the make?

> Finally, I'm sure this is my fault, but modules like "mousedev" and "sd_mod" 
> don't get loaded by hotplug/udev when I plug in my mouse or pendrive after 
> booting. This is because they are not actually dependencies of the modules 
> usbhid and usb-storage, so they don't get loaded by modprobe.

For scsi see here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hh3a22a2bb756566b7e18a57231bae9913e61da2;hbV18b5611bccf64a1e22f8cbcebe8ecba9713c9c;f=etc/udev/suse/udev.rules#l158

And better compile mousedev in the kernel. That does not make a lot of
sense as a module. If you really want a module, load it with an init-script.

> udev 053 used to do this, 067 doesn't any more. I've got both the 
> udev_run_devd and udev_run_hotplugd binaries compiled and in the right place; 
> I stole the configuration from the gentoo rules. Any idea what's changed?

No idea what's changed. Probably one of the hotplug agents is not
called, but we want to get rid of them anyway. :)

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel