Re: 2.6.6/udev weirdness

[Daniel Drake <dsd@gentoo.org>]

Hi,

Russell Neches wrote:
> Actually, I think the wording is quite clear in that section. I
> reckoned that I was having a different problem, though. My origional
> rules did, after all, work exactly as I wanted them to under
> 2.6.5. It's easy enough to see why one would want to distinguish
> between sda and sda1 and how to do it. My problem wasn't that I
> couldn't figure out how to solve that particular problem, it was that
> the behavior changed between minor version numbers of the kernel.

Yes, but your rule was problematic. It was being applied for sda, sda1, and 
also sg1 each time. I'm not sure if udev uses the first or last match, but 
either way, it was effectively choosing 1 and discarding 2. I've seen rules 
like this change their behaviour over reboots, and I suspect that might have 
been what caused it (rather than the fact that you upgraded kernel). You were 
just lucky that your rule worked originally (1 in 3 chance), and then your 
luck ran out :)

> I had thought (incorrectly, it seems) that sysfs is intended
> specifically to provide a standardized, reliable source of hardware
> information, and that the whole point of the thing was to prevent
> problems like the one I noticed. If sysfs is going to be a mix of some
> values that aren't supposed to change, and some that do, or might, or
> can, or could change (aside from chanes to _enforce_ compliance with
> policy), then it's much less useful. 

I'm 99% sure that the relevant parts of _sysfs_ would have stayed identical 
over your kernel upgrade. The problem is that your _udev_ rule was matching at 
least 3 areas of sysfs each time: scsi generic (sg1), scsi disk (sda), and 
each partition (sda1, sda2, ...).

This is where the section of the doc explaining about specificity comes in. I 
was trying to explain that you need to be specific about the partition/disk 
you are selecting, otherwise you might get something "useless" (e.g. 
unmountable node).

I'm not suprised that you experienced that the behaviour of your rule changed 
over time, even if we think it was triggered by a kernel upgrade.

> If there is some way of knowing which values may be expected to "stay
> put" between kernel revisions, then that goes part of the way to
> fixing the problem.

I think you have gone beyond the problem here. *If* the kernel upgrade caused 
the change in behaviour for your particular rule, then it will have been due 
to something like the timing of module loading changed, or the code used to 
create the sysfs tree being moved into an earlier/later stage of 
initialization, *not* because the sysfs values changed.

Daniel


-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
_______________________________________________
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