ifconfig and the Hurd
(I am not subscribed, if you expect a reply, CC me).
I saw on your web page that you wonder about the GNU Hurd, ifconfig, its
semantics and Linux scripts relying on that.
First, please use the proper name, "the Hurd" (not HURD or anything like that).
The Hurd has networking in a server of its own, which runs in
userspace. This server is configured on its command line like other
servers in the Hurd. You can change the command line of a server at
run time with fsysopts, a utility specific to the Hurd. And you can
make changes persistent by changing the translator setting, which is
scribbled into the filesystem.
So, we are very much unlike BSD or GNU/Linux here.
However, for compatibility with Unix in general, I have written an
ifconfig utility that is part of the GNU inetutils package. This
package is very portable, by the way (hint hint ;) Note that the
current Debian version is a bit out of date.
The ifconfig in GNU inetutils is not complete yet, and it is only supposed
to work on BSD, I never really checked. However, it would be command line
compatible with ifconfig as it is known on BSD, not on GNU/Linux. (It is
command line compatible to the systems ifconfig it was compiled for).
(This is all theory... command line compatibility is also mostly missing)
It has also its own command line syntax.
The output is configurable, though (I should say highly configurable :).
So, long story, short bottom line. We don't deal with GNU/Linux
networking scripts at all. We don't need to set up the network at
boot time either (Hurd servers are started automatically on demand
with the configured options when required). And, everything that goes
beyond the simple IP address, gateway, netmask and broadcast address
setting is probably too system specific anyway.
At one time ifconfig in GNU inetutils might be advanced enough to be used in
Debian. Then it provides its own command line options (as every GNU tool)
that could be used by all Debian systems for the basic settings. So, this part
of the problem is potentially solvable.
But in general, I don't think there is any reason to bother. You will
stumble upon a hundred packages or so which rely on Linux specific network
interfaces or features, and you will have to ignore them or replace them with