#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:23 LydianKnight]:
> trying to give consistent names to network devices in the chroot phase
using the variety of proposed methods seemed a bit strange for me (and the
reason why I always used the CLFS book for udev)
You don't mind if, while you're running through CLFS's section 11.13, you
don't know what name the card will have when you do boot?
I would definitely mind. But maybe that's just me. :-)
> LFS has an educational value, and trying to do the work for the users
doesn't seem to be quite educational
That is true. Ideally the user would go investigate what the commands do,
which could lead into a lot of knowledge about netlink, select, udev's
internals, etc., but that probably isn't very likely. Of course, the same
could be said of all the package installation instructions: if someone
just copies and pastes, they won't learn anything no matter how we do it.
;-)
That being said, I'm not sure how to make it more educational, while still
not going overboard duplicating effort. Upstream already has a system
that works in tons of cases, including systems that I haven't ever heard
of (e.g. S/390); I'd rather not duplicate that if we can use it.
(True, the book doesn't support S/390. But there's all the work that went
into wireless cards whose drivers create multiple interfaces, and Xen
devices, and external-tool support. Plus there's the work that will go
into the next change that needs to be made to handle some new type of
card; I'd rather let udev figure all that out and just use it, rather than
having to copy it.)
> BLFS has a chapter for naming (for example) the CDRW drive and so on,
giving a persistent name for the network card shouldn't be more difficult
than that
It isn't difficult if you only have one card, or have physical access to
the machine and don't care if networking comes up correctly on the first
boot ("do nothing" would suffice there ;-) ). But it is more difficult if
you have two wireless cards, or if you have a Dell server and want to use
biosdevname for its NICs. Or if you want to use some completely different
tool to generate the names.
Maybe none of that is needed in most cases. But I've never liked the
80/20 rule. :-P
> write some text indicating some examples of rules to accomodate for a
certain piece of network hardware,
This seems to be what we did in the 6.2 book
(http://www.linuxfromscratch.org/lfs/view/6.2/chapter07/network.html for
instance)? Note all the exceptions below the example rules; that list is
longer now. Should we keep that list in the book (including additions to
it), or expect the user to find it on their own? Or not support that
hardware (which I think is equivalent to "expect the user to find it on
their own")? Or something else?
Since upstream has already written a set of rules that will work for all
these cases already, I'd like to simply use them. :-)
(I realize I've basically disagreed with everyone that responded to my
comment request. That doesn't mean I don't appreciate the comments,
though: thank you all! :-) At minimum, they've helped me figure out what
exactly was needed, and why I want to go the way I want to go.)
--
Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:25>
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
