Creating a new thread as this is OT for the original thread. The message
being replied to can be found here:
http://linuxfromscratch.org/pipermail/lfs-dev/2006-May/057173.html

On Mon, May 15, 2006 at 10:19:37AM +0600, Alexander E. Patrakov wrote:
> 
> that's even more variables to look for. Therefore, _any_ of the rules below 
> will result in /dev/cdrom1 -> hdd symlink on my system:
> 
> ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"

#1 

This method requires that we know which ide controller the device is on
and whether the drive is master or slave (I would hope most would know
that just by the kernel output seen at boot).

However, this isn't device persistence. This is location persistence.
Not a bad thing by any means, but it must be agreed that location
persistence is sufficient if we are to use this. This is how cdrom
symlinks have always been. They point to a specific /dev/hd? node (where
? is traditionally based on the bus path) whether there is anything
there or not. This method just uses the bus path instead of the /dev/hd?
in making the choice.

If location persistence is agreed upon, then I prefer this method.
However, I prefer device persistence personally.

> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_PATH}=="pci-0000:00:07.1-ide-1:1", 
> SYMLINK+="cdrom1"

#2

This is another form of location persistence. ID_PATH is more unique,
but overly so in that it gains us nothing over the 1st example. Also,
ID_CDROM is not needed because the person writing the rule should know
whether or not it is a certain type of device.

I do not care for this method.

> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_MODEL}=="PHILIPS_CDD5301", 
> SYMLINK+="cdrom1"

#3

Again, ID_CDROM isn't needed. ID_MODEL would probably work for more than
90% of the people out there (I've never had or known anyone to have 2
identical cd drives in one machine, but it could happen). This one
provides true device persistance. It doesn't matter where this device
hangs on the IDE chain. The symlink will always point to it.

If the danger of uniqueness is considered acceptable, and if device
persistence is desired more than location persistence, then I vote for
this option. Any attempt to make ID_MODEL unique by specifiying
location, though, makes this no better than the 1st example.

> Or even, if one doesn't have add-on IDE boards (so that all of the IDE 
> channels are managed by one driver):
> 
> KERNEL=="hdd", SYMLINK+="cdrom1"

#4

This I wouldn't want to assume.


For a 5th option, we could use (in the case of Alex's drive):

ACTION=="add", ENV{ID_SERIAL}=="5VO1306DM00190", SYMLINK+="cdrom1"

This is true device persistence without the problem of uniqueness
associated with #3 above. However, it suffers from a similar flaw: Some
older drives do not have a serial number (at least not one that udev
will know about).


I personally prefer #3 and #5, but #1 might be better for the book
because it doesn't have any "what if's".

-- 
Archaic

Want control, education, and security from your operating system?
Hardened Linux From Scratch
http://www.linuxfromscratch.org/hlfs

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to