Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Hurd Traffic #45 For 26 Apr 2000

By Zack Brown

Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?
Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs?
Are you finding it frustrating when everything works on minix? No more all-nighters to get a nifty program working?
Then this post might be just for you :-)
-- Linus Torvalds, 1991

Table Of Contents

Mailing List Stats For This Week

We looked at 10 posts in 40K.

There were 6 different contributors. 1 posted more than once. 1 posted last week too.

The top posters of the week were:

1. PPP: Saga Continues

16 Apr 2000 - 20 Apr 2000 (5 posts) Subject: "A strange thing happened today"

Topics: Networking

People: Adam SampsonIgor Khavkine

Another chapter in the ongoing 'ppp' story (see Issue #39, Section #2  (4 Mar 2000: PPP/pfinet Saga Continues) ). This time, in the course of discussion, Adam Sampson suggested:

an alternate tack for getting Hurd a PPP implementation, how about implementing a workalike of FreeBSD's "tun" driver and nicking their userspace ppp daemon? From the tun(4) manpage:

The tun interface is a software loopback mechanism that can be loosely described as the network interface analog of the pty(4), that is, tun does for network interfaces what the pty driver does for terminals.
The network interfaces are named tun0, tun1, etc, as many as were made by MAKEDEV(8). Each one supports the usual network-interface ioctl(2)s, such as SIOCSIFADDR and SIOCSIFNETMASK, and thus can be used with ifconfig(8) like any other interface.
Once the interface is ready, read() will re- turn a packet if one is available; if not, it will either block until one is or return EWOULDBLOCK, depending on whether non-blocking I/O has been enabled.
A write(2) call passes a packet in to be `received'' on the pseudo-interface. Each write() call supplies exactly one packet; the packet length is taken from the amount of data provided to write().

It looks like this would be a much easier job to implement than PPP as a Hurd server.

Igor Khavkine replied:

I think that would be a very good idea. I actually looked at pppd to see how much work would have to be done in order to port it to Hurd. The pppd itself is pretty platform independent with the exception of functions that deal with the serial port, changing network routes and the like. Also all platform dependent functions are bundled together separate from the main code.

Two things stopped me from exploring this further: the lack of a development Hurd machine and my blatant ignorance regarding network interfaces. For example I'd have no idea what kind of functionality a "tun" driver might implement.

However I do have an idea of what should be done. pfinet must be extended to handle multiple interfaces at the same time, and of different types. And pfinet must support changing the routing information at runtime. I think there was a patch for that floating around, but I didn't look into it much. And then the "tun" driver might be implemented. Also having such a generic network interface will enable us to support protocols other then PPP, implemented outside pfinet and it may even be possible to bring the Ethernet interface support out of pfinet as well.

End of thread.

2. libgc5 On The Hurd

19 Apr 2000 - 20 Apr 2000 (3 posts) Subject: "libgc5 port to Hurd"

People: Chris Lingard

Chris Lingard sent a patch for libgc5 to Mike Goldman (Cc:ing debian-hurd), and said, "I wrote to you last March about a port to the Hurd." [...] "Would you please apply the attached patch to the source. I have checked that its makes no difference to Linux builds. This is my first patch to a Debian maintainer, so not sure of the procedure or methods. On the Hurd I have checked libgc5 by building packages Bock, Open++, Stalin and W3m." There was some small discussion about the patch, but not much.







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.