From mboxrd@z Thu Jan 1 00:00:00 1970 From: Darren Salt Date: Fri, 30 Dec 2005 19:47:38 +0000 Subject: Re: new version of udev has different cd/dvd devices Message-Id: <4DE185373D%linux@youmustbejoking.demon.co.uk> List-Id: References: <43B313ED.40402@bl.com> In-Reply-To: <43B313ED.40402@bl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org I demand that Kay Sievers may or may not have written... > On Fri, Dec 30, 2005 at 06:16:54PM +0000, Darren Salt wrote: >> I demand that Greg KH may or may not have written... >>> On Thu, Dec 29, 2005 at 12:29:36AM +0100, Kay Sievers wrote: >> [snip; creating static rules on-the-fly] >>>> Distros could also have a "default" rule, which catches unconfigured >>>> devices and automatically creates a rule for them to keep the name >>>> stable across reboots. >>> Or we can just stick with the rules we have today that use %e just fine, >>> as it emulates exactly what a static /dev would have done, and no one is >>> complaining about it :) >> Well, other than that it's become broken along with various other things >> (in my case, ALSA sound device numbering; fortunately, the machine in >> question has just the one external network interface) due to a change >> elsewhere. And we all know what that change is, don't we :-) >> A switch which says "process events in series" or "process events which >> match this rule in series" (hmm, groups of rules?) would do for my >> purposes. Faster booting's all well and good, but I think that the cost is >> just a little bit too high in this case. > Forget "order" of devices on a system where everything can come and go at > any time. Hmm. Drivers built into the kernel, devices require shutdown for replacement... well, that's the case for my DVD drives. > The time can we configure a system once at installation is long over. I don't recall making any mention of one-time configuration. > Make the system aware of persistent properties and use that. It can all > work automatically if done right. It was done right before, at least for those of us for whom the bus order happens to be the order which we want for devices which are normally present at boot. If others need something else, fine, add that... > There is simply no "order" anymore we could rely on. Bus address? Or does that change on reboot too... > So start to think in the right direction and help solving the real problems > instead. => fix the regression by restoring previous behaviour. That would solve the real problem that I'm seeing. > It has nothing to do with "faster booting", I *could* be conflating or misunderstanding things here... > it's about dynamic system configuration. You can't have both at the same > time: hotplug and static configured systems. Well, of course not: a static system would completely preclude the possibility of hotplugging. Now, if you mean "statically configured system"... let's say "statically configured subsystem" instead. This tends to be PCI, IDE and maybe some others or parts of others, and these tend to be fixed. (Yes, I'm aware that there are hot-pluggable implementations...) I don't see what the problem is with automatically allocating names in a reliable manner to fixed devices. If you want a fixed name for something hot-pluggable, fine, write some extra rules. > But if we do it right, we can have a completely dynamic system, that works > reliably and is predictable. Hmm? ISTM that we _had_ that. > But that has absolutely nothing to do with device probing order, kernel > device names, Er, yes it does. Device naming worked here because of them. > or devfs-like naming schemes. I didn't mention that... Maybe some symlinks in the static /dev should be used as seeds for udev-managed /dev? That'd provide some or possibly all of the fixed device names, avoid some rule writing, and provide the same naming for those devices in emergency-boot situations (where I tend to use init=/bin/sh and expect /dev/hdaX to be mounted). [snip] -- | Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington, | Debian, | s zap,tartarus,org | Northumberland | RISC OS | @ | Toon Army | (PGP 2.6, GPG keys) There are no giant crabs in here, Frank. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&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