Hi, (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). Thank you. 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 your own. Thanks, Marcus
