From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sat, 31 Dec 2005 00:04:19 +0000 Subject: Re: new version of udev has different cd/dvd devices Message-Id: <20051231000419.GA7161@vrfy.org> 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 On Fri, Dec 30, 2005 at 07:56:52PM +0100, Kay Sievers wrote: > On Thu, Dec 29, 2005 at 11:46:59PM -0800, Greg KH wrote: > > Yeah, but we still need a way to enumerate devices in some kind of > > order, like we do for the cdrom devices today. So I don't think we can > > drop it entirely. > > We don't have any "order", that's why we can't do it that way. The > persistent /dev/disk links are working without any "order", that's the > model to follow, or writing out "automatic rules" to provide stable names. > Everything else will just not work. The problem is we need to "name" devices reliably, without depending on discovery-order enumeration. %e is also used to enumerate over different subsystems like hd* and sr*. That probing order can't provide "stable" names. On SUSE we never used %e for that reason and the system management creates rules for optical devices which just match on ID_PATH. That works pretty well in all currently known setups. For systems/distros who don't have such a central system management, we may want some kind of "auto rule creation" for optical devices to provide stable names. Something like a script that checks, if a device is already catched by a persistent rule and if not, it names the device uniquely and at the same time it drops a rule line to a file in /etc/udev/rules.d/. So the next time the device shows up, the same name gets assigned. That file can be edited by the user, if he wants a different name. That "auto rule setup" could run from udev itself, but may not work in all cases where /etc is not writable on bootup, or it can be triggered by running the script manually, once after adding new hardware. That sounds like the only sane and future proof option to me. Anybody willing to try this? I shouldn't be hard to implement this as a shell script. Any code, ideas, comments? Kay ------------------------------------------------------- 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