Archaic wrote:
If location persistence is agreed upon, then I prefer this method.
However, I prefer device persistence personally.
For network devices, device persistence is already in the book. Of course one
could implement location persistence instead :)
ACTION=="add", BUS=="pci", ID=="000
Jeremy Huntwork wrote:
Alexander E. Patrakov wrote:
+1, because I don't believe in educational value with udev. For most
of BLFS editors, it's a black box. Editors just expect someone to
configure udev properly, so that they don't have to think about it.
Unfortunately, udev is one of the packa
Archaic wrote:
ACTION=="add", BUS=="ide", ID=="1.1", SYMLINK+="cdrom1"
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.
ACTION=="add", ENV{ID_MODEL}=="PHIL
Alexander E. Patrakov wrote:
+1, because I don't believe in educational value with udev. For most of
BLFS editors, it's a black box. Editors just expect someone to configure
udev properly, so that they don't have to think about it. Unfortunately,
udev is one of the packages that _require_ compl
Jim Gifford wrote:
There is one more solution, which will prevent all udev issues
altogether. Going to MAKEDEV.
+1, because I don't believe in educational value with udev. For most of BLFS
editors, it's a black box. Editors just expect someone to configure udev
properly, so that they don't ha
On Sun, May 14, 2006 at 10:29:30PM -0700, Jim Gifford wrote:
> There is one more solution, which will prevent all udev issues
> altogether. Going to MAKEDEV.
I fail to see how that cooresponds to anything I said. This thread is
about persistence with udev, not udev vs. MAKEDEV. Please provide
com
There is one more solution, which will prevent all udev issues
altogether. Going to MAKEDEV.
http://people.redhat.com/nalin/MAKEDEV
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
