From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Drake Date: Mon, 17 May 2004 09:49:04 +0000 Subject: Re: 2.6.6/udev weirdness Message-Id: <40A89868.10306@gentoo.org> List-Id: References: <20040512235509.GA3836@heliopause.vort.org> In-Reply-To: <20040512235509.GA3836@heliopause.vort.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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