On Sun, Feb 26, 2012 at 12:22 PM, Qrux <[email protected]> wrote: > > On Feb 26, 2012, at 10:20 AM, Bryan Kadzban wrote: > >> Qrux wrote: >>> For 7.2 & beyond... >>> >>> Bridge-utils is not dissimilar from udev, in that it's a userspace >>> tool for a kernel. And, it's certainly no less optional than >>> inettools. >> >> hostname is required for X (it runs "hostname -f" at startup), and >> ping/traceroute/telnet are extremely useful when debugging broken >> networking. > > I do realize that it seems many users of *LFS are quite concerned with things > that run X. X is obviously great for a desktop. That doesn't mean it's the > only use-case, and X doesn't seem an appropriate justification for LFS > inclusion, AFAICT, given how free of bloat LFS is. In fact, that same lack > of bloat makes it wonderful for server installs, especially for > virtualization environments where you don't want to clone all kinds of stuff > that guest OSes need. > >> But brctl is utterly useless, *unless* you're running a bridge. (Or >> you're trying to create firmware for a switch, which is just a >> larger-than-two-devices bridge.) I doubt most people are doing either >> of those two things. > > This is not merely a question of usage. It's also an engineering tradeoff > about coupling and closure, not to mention I think you're missing > another--possibly the single most popular--use of bridging. Every > virtualization setup now requires either bridging or routing, and many choose > bridging for the simplicity. You may want to look into KVM, or Xen, or > VMware, to get some scope of how ubiquitous virtualization (and bridging) > might be. That's simply to say that bridging may not be as rare as you > perceive. > >>> Ethtool is the same story...another userspace kernel tool to inspect >>> hardware. It replaces mii-tool, now deprecated. >> >> There is no ethtool package in either BLFS or LFS, and no mention of an >> ethtool binary in any of the other packages either (at least as far as >> Google will tell me). mii-tool is not in LFS either, ever since >> net-tools got ripped out, several versions ago. > > You seem to be getting hung on up on the fact that 'grep ethtool' isn't > showing results in your sandbox. I'll try to boil it down. Net-tools is in > BLFS (stable & svn): > > http://www.linuxfromscratch.org/blfs/view/svn/basicnet/net-tools.html > > http://www.linuxfromscratch.org/blfs/view/stable/basicnet/net-tools.html > > It installs mii-tool as part of the package, along with arp, hostname, > ifconfig, netstat, rarp, and route (useful tools) and lesser-useful things > (plipconfig, nisdomainname). On a related note, arp and netstat are also > quite useful for network debugging. But, back on track... > > Point 1: ethtool, minimally, should replace mii-tool in BLFS. > > Let's say that it makes sense to add it to BLFS as it's a direct replacement > for something that no longer works and is officially deprecated. Hopefully > that addresses the grep issue so we can get at the more salient points. > >>> So, I propose bridge-utils and ethtool be moved into LFS. >> >> For the reasons above, I disagree. At least on bridge-utils, though >> ethtool doesn't even exist in BLFS, so that's pushing it too I think. > > Point 2: ioctl-like utilities should always, at least, be considered. > > Things like udev, blockdev, brctl, and ethtool give userland access to the > kernel in areas which are currently in use by LFS; i.e., if you use a disk, > you probably want blockdev. If you use userland devices (USB sticks, > whatever) you probably want udev. If you use a NIC, you probably want > ethtool, particularly if troubleshooting is to used as rationale. Like, if > you have a misbehaving switch (or w/e) that isn't negotiating properly. Port > failures and mishaps happen. And, as much as traceroute or ping is useful > for you, so might ethtool be for someone hoping to optimize their network > performance or debug a bum network. > > Now, before we make comparisons to stuff like NFS, ethtool is distinct from > stuff like kernel-NFS-userland. Sure, NFS-userland also provides userland > access to kernel functions--but those functions are not in LFS. So, since > NFS isn't in the book, you don't have to provide NFS-userland, even if you > build NFS in the kernel. Nothing will ever require NFS-userland, until the > user decides to run NFS. As such, since it doesn't impact the rest of the > system, NFS doesn't--and shouldn't--be in LFS. So, we can use a closure > argument to explain why NFS doesn't belong...And, that same closure argument > should explain why I'm proposing ethtool. It's a simple little thing, tied > to the kernel, that gives debugging info about a *facility provided in LFS*; > namely, basic Ethernet & TCP/IP networking. I think the closure and usage > arguments are compelling. > > Which brings us to: > > Point 3: brctl is representative of more complex network configs... > > ...many of which have upstream requirements on networking scripts in LFS. > Having one of these "more-complex" systems in LFS would greatly help mitigate > those skews by having more eyeballs on it. It's no one's fault, obviously. > But, LFS *does* provide networking scripts. So, given their nature, if you > want to exclude things like bridge-utils (and demand that they appear in > downstream stuff) it implies that those networking scripts end up having an > inverted dependency on downstream stuff. > > Now, to be my own devil's advocate...Sure--on the surface--brctl doesn't meet > the closure requirement, since nothing depends on it in LFS. Obviously, > people are getting along without it. But, downstream things *do affect it*. > That's just not good encapsulation, which is the engineering tradeoff I was > referring to earlier. Obviously, while it doesn't completely solve the issue > of how to identify issues in if{up,down}/services that downstream stuff > reveals, it does ameliorate the issues that arise from having an > overly-simplistic (though, admittedly, closed) scheme of networking. In > addition, I think there's a reasonable usage argument (re: virtualization). > And, it does provide an ioctl-like interface. More importantly, there's a > bit of a closure violation when bridge-utils exposes errors in those scripts, > and requires that they be fixed, sometimes radically. > > I am fully aware that including brctl in LFS is not a cure-all; I'd love to > hear ideas about how to keep the LFS networking scripts aligned with > downstream users. The tradeoff is including 1 additional package for the > functionality it brings and the upstream problems it could help identify and > mitigate. If we don't include it, I'll deal with that. Which means I'll > probably continue to update those scripts and feed them back up to LFS. I > just don't think the arguments of: > > * X needs hostname, but surely not brctl because... > * No one I know runs a bridge--or writes bridge firmware--and... > * I don't see ethtool in BLFS nor do I know what it is, > > ought to be the determining factors. > > As a closing thought, consider psmisc as an analog. Here's what it provides: > > * fuser > * killall > * peekfd > * prtstat > * pstree > * pstree.x11 > > Are you saying that those utilities that give a userland view of the kernel > are inappropriate? I would agree about things like pstree. I was once > hacking around on a TiVo box that didn't have ps (hardcore) but had a working > procfs. Luckily I was able to get the info I wanted, but after that > nightmare I think 'ps' is important even for a minimal system. OTOH, I think > pstree is probably going a bit far. Similarly, fuser is a nice inclusion--it > provides an orthogonal service. But, if you make that claim, how is it > different than ethtool? They are both technical tools, they both provide > userland views into the kernel, and I think it's safe to say that whatever > generality of usage you apply to fuser would analogously apply to ethtool. > > When all is said and done, I'm talking about two tiny little "packages" > (bridge-utils and ethtool) that amount to probably 2 executables that control > and expose kernel features very close to the core system. There are less > justifiable executables in the current system. > > Q
Gerard Beekman has said in the past, that LFS was not a minimal system, but a full fledged development system. I think it was the psmisc that was being discussed back then. For myself, I use bridgeutils to provide networking for qemu (and have been doing this for years now), but I would never consider it that essential that it is required in LFS. [blfs on the other hand, perfect place]. I admit, I have never looked into what ethtool does. -- Nathan Coulson (conathan) ------ Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
