#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:26 LydianKnight]: > although I think the vast majority of users won't have more than one network adapter, wired+wireless at best And even if you have one wired/one wireless, you will usually have different basenames for the two interfaces (ethX versus wifiX/wlanX, athX, raX, etc.). :-) > take a quick look at the /sys hierarchy, and after I've found something interesting, I run udevtest with the desired parameter to inspect some of the capabilities and information for a given adapter (same case as the naming for a CDRW drive, for example) Yeah; with some knowledge about all the different interfaces in the system (not just cards), and what makes each one unique, this works OK. The issue is, if you don't know the pitfalls for your driver(s), it's easy to fall into them. :-) > > Maybe none of that is needed in most cases. But I've never liked the 80/20 rule. :-P > > Maybe my point of view sounded a bit selfish Not really -- that 80/20 comment was more because I hear a lot of it at work. I don't really agree with a "The last 20% doesn't matter enough to worry about!" type of a mindset. It works out OK if you're looking at some physical system -- usually, anyway -- but software is usually a lot more complicated. There is a limit beyond which you shouldn't worry (and maybe these multi-NIC cases are beyond that limit), but the limit is almost never at 80%; if only 80% of some system works, it's still too buggy, IMO. :-) (Plus I always seem to be using the last 5%: the stuff that got left buggy because of some other group's equivalent of 80/20. :-P ) > we could add some text about the /sys hierarchy This is probably a good idea anyway. At least an overview of what's where in current kernels, and how to find stuff starting in e.g. /sys/class or /sys/bus. > (but frankly speaking, would be nice to see this effort reaching a stable solution for all, no other distro seems to have reached a proper solution (at least debian like it's mentioned) and hey, that would definitely be a great point for LFS) You're right, but I think the reason other distros don't need this is that they don't really care what happens if you move from another distro to them. You go via their CD (probably just like Debian), and their CD can generate the rules. LFS is fairly unique that way, I think. > we're not asking users to patch/sed some lines of code in a given file to be able to accomodate their purposes, but to inspect a bit their new system to customize it a bit more Yeah, that's true, and maybe it's not terribly difficult. I guess my biggest issue with having users write the rules themselves is probably that I don't expect users to need to know whether their card requires a "special" rule or not, which means we'd have to tell them (or have them get it wrong). We'd have to keep track of which type of setup would require extra match keys to work right, and if that gets missed (either we miss a new special setup, or if the user skips that section), then the whole system fails. -- Ticket URL: <http://wiki.linuxfromscratch.org/lfs/ticket/2057#comment:27> 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
