#2057: Udev-122
------------------------------------------+---------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [email protected]
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0
Component: Book | Version: SVN
Severity: normal | Resolution:
Keywords: |
------------------------------------------+---------------------------------
Comment (by Bryan Kadzban):
Replying to [comment:28 [EMAIL PROTECTED]:
> and we should state this goal explicitly and provide a way to check this
That sounds like a pretty good idea, actually.
> (e.g., say that the *_rename interface will appear after the reboot in
the case of an error).
Hmm; I'm not sure that after the reboot is the best time to test it: it's
already too late if you don't have (easy) physical access to the machine.
But that's just an example, too.
What may work is using udevtest, if we don't mind using it. (Not sure on
the status of it upstream: at one point I think it was slated to
disappear, but that was before the ability to read from the sysfs uevent
file was added to the kernel.) If we run udevtest inside chroot for each
NIC and make sure each one gets a different NAME applied, that may be
sufficient. Catching bugs that have to do with cards getting random MACs
would be a problem, though.
The rules won't be nearly as nice-looking as the ones that upstream
generates, either. Whether that matters or not is a different issue
though. :-)
(Actually, one thing I haven't tried is seeing whether udevtest runs
IMPORT{program} keys. If it does, that may solve all the issues. Let me
test it...)
HAH! That should work fine. :-) OK, a new option: Unless udevtest is
evil for some other reason, we can just run:
{{{
for i in /sys/class/net/*[0-9] ; do
udevtest $i
done
}}}
, and that will pre-generate everything. It will run the IMPORT programs
just like udevd would. Unless I'm missing something critical, this should
work as long as udevtest keeps working that way.
Replying to [comment:29 [EMAIL PROTECTED]:
> So the only way to get out of this situation is to write location-based
or driver-based rules manually.
Well, that's one way to fix it. Another way could be to let all the
"local" MAC address cards get randomly-assigned names that grow from the
top of the numeric range, and let all the "real" MAC address cards get
persistent names at the bottom of the numeric range.
For instance, say you have four cards, two of each type. Give the first
"real" card that gets rules generated for it eth0, and give the second
"real" card eth1. The other two cards will be given some name up higher;
they could probably trade off between eth32767 and eth32766 (assuming the
"top" of the range gets set to the maximum 16-bit signed integer).
(Of course, path-based rules are probably easier. They'd be even easier
if path_id wouldn't require a "dev" attribute in sysfs for the DEVPATH in
question; NICs don't have one. :-) )
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:32>
LFS Trac <http://wiki.linuxfromscratch.org/lfs/>
Linux From Scratch: Your Distro, Your Rules.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
