Re: Possible udev bug and some questions

[Martin Schlemmer <azarah@nosferatu.za.org>]

[-- Attachment #1: Type: text/plain, Size: 4682 bytes --]

On Thu, 2003-12-25 at 02:19, Greg KH wrote:

> > 1) if you look at the following code in namedev.c (in
> >  function do_callout()):
> > 

> > there is a slight problem - if sysfs_device = NULL, then the
> > 'strcasecmp(dev->bus, sysfs_device->bus) != 0' test will never
> > be evaluated, and result in the callout to run for all non-phisical (?)
> > devices.
> 
> Ah, good catch.  I've put a test in the udev-test.pl script to catch
> this bug, and added the following patch:

> I also made the BUS key optional for the CALLOUT rule.  If the BUS value
> is not present, then the CALLOUT rule is always called.  Does this work
> for you?
> 

Seems Ok, thanks.

> > 2) If I understand the udev manual correct, all 'methods' should have a
> >  suitable 'key'.  If I now look again at namedev.c, then whenever we
> > work with a non-phisical (?) (or not attached to a phisical bus?)
> > device, then non of the 'keys' used with 'methods' are available, as
> > get_sysfs_device() fails.  Should any of the 'methods' then be run?
> > Or more to the code, should any of the do_* (do_callout, etc) functions
> > then be called for a device for which get_sysfs_device() failed?
> 

> Right now, if we can not find a sysfs_device, we can still run most of
> the rules.  LABEL works, CALLOUT now works, NUMBER makes no sense at all
> without a sysfs_device and does not work.  Same thing for TOPOLOGY.
> Then REPLACE works too.
> 
> So without that link, we do the best that we can.
> 

Ok, makes sense - just wanted to verify if I should look deeper or not.

> Is there something about the way devices without a sysfs_device works in
> udev today that you do not like (except for the above bug...)
> 

No.  Once again, I was not sure about CALLOUT, LABEL, NUMBER and
TOPOLOGY, but CALLOUT is fixed, and according to your other mail,
so is LABEL, and NUMBER and TOPOLOGY have sufficient checks for
valid sysfs_device.

> 
> > 4) Is there any reason why only one 'method' (meaning only one of the
> > callouts I may have for ide devices - I may want to use both the
> > ide-devfs.sh and ide-devfs-compat.sh to have multiple symlinks for on
> > device ...) is done for each device and/or hotplug event (beside lack
> > of time to implement) ?  Same for why only 'type' of 'method' is done
> > for each (if a CALLOUT is done, the rest is skipped) ?
> 
> We stop comparing when we find the first rule that succeeds.  Otherwise
> how are we going to handle "catchall rules"?  I don't want to have to
> come up with a situation of weighting rules, and if more than one
> matches, determing what needs to be done (both, none, one, etc.)
> 

I was thinking more of 'find one, do whatever, find next, do whatever'.
I can see however that this could get messy.

> If you want to call two callout scripts, just make a new script that
> calls them both :)
> 

I do not see how to do that, except if you let the scripts create the
symlinks/whatever, which is not entirely what I want.

Let me give an example that do not use CALLOUT:

LABEL BUS="scsi", SYSFS_type="5", SYMLINK="cdroms/cdrom%n"
LABEL BUS="scsi", SYSFS_type="5", SYMLINK="sr/%n"

Silly/may_not_work example, but it basically shows that I want two
symlinks for the same thing ...

The only other logical way I can think of, is to be able to stack
SYMLINK like so:

LABEL BUS="scsi", SYSFS_type="5", SYMLINK="cdroms/cdrom%n",
SYMLINK="sr/%n"

which does not work currently.  That Ok with you?

A note though - I tried a quick hack for above with the help of the list.h
stuff (needs some more work to not actually segfault :/), but then I got
to the db stuff, and realized that it will be a slight issue to a link list
saved with the tdb stuff - much hacking.  Other ideas that may be easier?

> > 5) I use a devfs-less setup with udev, 2.6.0 kernel with most of the
> > sysfs patches from Greg, if not all, and a pre 2.3.3 glibc.  Also
> > have devpts compiled in, and mounted to /dev/pts.  I now have the
> > following 'w' output:
> 
> Are you using udev to manage your /dev tree?
> 
> 'w' works for me without using udev to manage my /dev tree.  Try that to
> see if it's a udev issue or not.
> 

Bah, my udev.permissions was too gracious with test for /dev/pt*
(parallel tape drives), and set /dev/ptmx with 0600 permissions as
well :/  Thanks anyhow for looking.


Last question - with the pending libsysfs fixes, will there still be
the need for the second or so delay?  Why I am asking, is because if
I want to generate devices in initramfs or such, it still will take
a long time ...


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]