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
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
