Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
Git
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Hurd Traffic #34 For 9 Feb 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

Introduction

Sorry about missing last week's issue. Don't worry though! This week covers everything from both weeks! Enjoy!

Mailing List Stats For This Week

We looked at 135 posts in 379K.

There were 48 different contributors. 19 posted more than once. 10 posted last week too.

The top posters of the week were:

 

1. Porting PPP
21 Jan 2000 - 24 Jan 2000 (6 posts) Archive Link: "i want to help ! how ?"
People: Marcus BrinkmannIgor KhavkineTomasz WegrzanowskiThomas Bushnell

This subject has been covered in Issue #26, Section #3  (28 Nov 1999: PPP Under The Hurd) , and then again in Issue #28, Section #3  (13 Dec 1999: FTP And PPP On The Hurd) .

Halis Osman ERKAN was excited to start hacking on the Hurd's kernel, and asked where to start. Marcus Brinkmann gave a pointer to www.debian.org/ports/hurd and recommended, "check out the development and tasks pages. Browse around a bit, come back with more questions." Tomasz Wegrzanowski also replied to Halis, and suggested that Halis try to port the PPP sources from Linux; which he felt would make the Hurd much more popular in Europe. Marcus replied that there was a lot more to PPP than just porting the sources. He suggested contacting Thomas Bushnell to get the relevant design information.

Igor Khavkine downloaded the PPP sources, and said that the package seemed to be fairly portable, and all system-dependant functionality seemed to be properly isolated. But he added, "However the most important part of the port is to introduce ppp support into pfinet. The current implemetation of pfinet is kinda shabby right now. From the looks of it, it can only handle one interface at a time and only either ethernet or loopback. So if anyone wants to port ppp, they should also rewrite pfinet." Marcus elaborated:

It's not rewriting pfinet, but integrating ppp with pfinet. AFAIK, Thomas thinks about something like a pump server that initiates the connection and forwards it to pfinet. Thomas knows the details about this, and this is the main work to be done for ppp support.

The one interface limitation should not be too hard to overcome. There already exist patches for that, but Thoms did not yet incorporate them.

 

2. 3Com905C-TX Problems
24 Jan 2000 - 3 Feb 2000 (7 posts) Archive Link: "Problems with 3Com905C-TX"
People: Michail Issakov

Michail Issakov tried connecting two PCs, each of which had a 3Com905C-TX Fast Etherlink XL NIC. One PC had FreeBSD, and one was a Linux/Hurd dual boot. The only problem was that Linux couldn't find the NIC. He tried Donald Becker's driver, without success; but he added, "I have solved this Problem for Linux with patching of Kernel with 3C90x-series driver from 3Com's page.FreeBSD-Linux network is working well. But my idea was to connect Hurd anyway to internet over the network. The sources of the driver are available. May be anybody had already ported this for Hurd ?" He concluded with a pointer to the Linux driver.

 

3. Dependency Issues; Crypto Apps
24 Jan 2000 - 25 Jan 2000 (6 posts) Archive Link: "general compilation questions.."
Topics: Apt
People: Marcus Brinkmann

Greg Olszewski installed the Hurd and had a number of things to report. First, he noticed that libncurses4 was listed as being in 'base' but was actually in 'oldlibs', so the script couldn't find it. Marcus Brinkmann replied that this was a bug in 'cross-install', and should be fixed soon.

Greg also pointed out that the bsdutils package wanted sysvinit, which wasn't available. Marcus replied that Greg should simply force the install. He also gave a pointer to an experimental sysvinit.

Greg also reported that apt 0.1.9 wouldn't install because debconf depended on apt 0.3.12.1; Marcus was taken aback that debconf would depend on apt, but added that apt 0.1.9 was broken anyway, and shouldn't be used.

Greg had also made some effort at porting openssl and openssh. Marcus replied that he'd already done work on that as well, but added:

If you want to take over with openssl and openssh, I can send you my current patch and what was already discussed with the openssl people. I wouldn't mind passing it on.

No patch will touch crypto code, so it should be safe to transmit the necessary patches back and forth.

 

4. Getting The Effective GID Of A Running Process
25 Jan 2000 - 26 Jan 2000 (7 posts) Archive Link: "libps"
People: Roland McGrathNeal Walfield

Neal Walfield couldn't find a way to derive the effective GID of a running process. Reading through ps.h was no help. He asked if there was a way to get that information, and Roland McGrath replied, "No, there isn't one. The proc server only returns you the owner uid (which is usually the same as the first effective uid). I suppose it could have a call to return full id sets for each process." He also asked if any UNIX would give the effective GID, and Neal quoted from the 'ps' manpage:

-G glist
writes information for processes whose real group ID numbers or names are given in glist. The glist is a list of process-group identifiers enclosed in " " (double quotes) and separated from one another by a comma or one or more spaces (or tabs), or both. Because of the way the shell treats spaces and tabs, you need to quote space-separated lists.

Roland couldn't seem to find a -G option on his Linux system, but added, regarding the man-page quote, "That is about selecting processes based on GID, which is different from showing the GIDs of processes. (Though the Hurd ps has neither.)" Neal and Gregory Ade both reported that on their recent Debian and Red Hat systems, -G was an accepted option.

End Of Thread.

 

5. Study Hurd Or Linux?
26 Jan 2000 - 28 Jan 2000 (5 posts) Archive Link: "Learning kernel-hacking"
People: Josip GracinFredrik LiljegrenMarcus Brinkmann

Fredrik Liljegren had never really looked over a kernel, but he was dying to start. He asked which was easier, going to the better-documented Linux, or diving straight into the Hurd. In a later post, he'd downloaded the gnumach, mig, and hurd cvs trees; and found the "GNU Hurd Reference Manual", which he stayed up all night reading. Someone had recommended that he might start with Linux, because of the better documentation, but he asked if the differences between Linux and the Hurd were so great that learning one would not necessarily help with learning the other. Marcus Brinkmann felt that yes, this was probably true, but Josip Gracin offered, "You could say that the differences are big but it's not that learning any of the systems first won't help you understanding the other. You shouldn't worry about that. Take one system and study it carefully. You first have to learn lots of things that are same in both systems. Eventually, you'll get to the point where the difference between the systems will become obvious and logical without much time spent on studying the other system."

 

6. Mach Discussion; Single-Server OS Vs. Multi-Server OS
26 Jan 2000 - 28 Jan 2000 (7 posts) Archive Link: "Mach Kernels"
Topics: FS: NFS, FS: ext2, POSIX
People: Marcus BrinkmannChristopher BrowneThomas BushnellR Joseph Wright

R Joseph Wright asked what the advantage was to using a mach microkernel. Did the developers choose it just because it was there and they didn't want to reinvent the wheel, or did it have some special features of its design, such as stability? He'd heard that Apple's new OS ran on mach, and was supposed to be uncrashable. Was this the reasoning of the Hurd developers?

Marcus Brinkmann drew the distinction that other mach-based OSes were single-server OSes, while the Hurd was a multi-server OS. He also pointed out that no OS was crash-proof, because there would always be bugs. In addition, he said that the Hurd did not have graceful out-of-resource handling, making it less stable than it could be at the moment. To the historical question, he replied that yes, as far as he knew mach was chosen because it was there, and the developers didn't want to reinvent the wheel. But he added, "Mach also offers a rich set of semantics to work from. However, the Hurd itself is mostly microkernel independent and could be ported to other microkernels."

R Joseph then asked what the difference was between a single-server and multi-server OS, and received several replies. Marcus gave a pointer to Thomas Bushnell's paper, Towards A New Strategy Of Operating System Design, and offered this explanation:

Beside the coexisting of several, probably emulated OS's, the Hurd itself is also being split into several servers.

Running a Linux, DOS etc server would not mean much: Each server would be isolated from each other. So you had several single server OS's running simultaneously.

When we say multi-server, we actually mean several servers who commnicate through each other, and know about each other. The Hurd is split up into several servers, according to the features of the OS.

For example filesystems are implemented in their own servers (ext2fs, isofs, ufs).

But also POSIX process semantics are implemented in a seperate server (proc), and partly in the C library.

Then there is the auth server to establish channels of communication between partners that don't trust each other.

More profane features like symlinks and fifos are implemented in servers, too.

Device files. Just look into /dev. Each one corresponds to a server (some server handle multiple devices, specified at the command line).

Network sockets and unix domain sockets are each in their own Hurd server.

Christopher Browne also offered his own analysis:

Compare to Linux.

On Linux, the "kernel" is one big process.

On Hurd, much of the functionality that, in Linux, is in that one big, monolithic program, gets farmed out to a set of processes known as 'servers.'

Hurd servers have included things like:

auth, crash, devio, devport, exec, ext2fs, fifo, ifsock, init, magic, nfs, null, pfinet, pfilocal, proc, symlink, term, ufs

A really cool part that falls out of this is that this means that you could conceivably hack on parts of the OS *while it's running.*

If a particular server is a bit buggy, it's at least *plausible* to restart it. In contrast, if the Linux kernel-based NFS server code "blows up," the whole system immediately goes down.

 

7. Debconf Installation Problems; Porting .deb Packages
30 Jan 2000 (2 posts) Archive Link: "New Install"
People: Marcus Brinkmann

David Starner installed the Hurd and it seemed to be working OK, but he reported that Debconf didn't want to install. It complained about something in Perl and /dev/fd/8

Marcus Brinkmann replied, "Known. Roland has investigated this a bit, but nobody really provided a solution."

David also asked what he should do if he succeeded in porting Debian packages to the Hurd. He had no permanent FTP site of his own (though he did have an intermittent one), and since he wasn't a Debian developer, he didn't have upload access to the official Debian FTP site. Marcus replied:

As soon as the package builds out of the box (from some Debian version without changes), I can easily build and upload it. You only need to tell me the package name and working version.

If you also want to make patched packages available to everyone until a fixed package is available is left to your discretion. Please post a link to this list if you do so.

 

8. e2fs Difficulties
30 Jan 2000 (2 posts) Archive Link: "e2fs and cd //"
People: Fredrik LiljegrenMarcus Brinkmann

Fredrik Liljegren reinstalled the Hurd just to keep his hand in, and remarked, "What strikes me from last time is that potato's current e2fs still makes a filesystem that hurd (or at least grub) has difficulties to read; so I had to downgrade to the stable again.. I don't know if this is a bug in e2fs or grub though; linux had no problems with it whatsoever." Marcus Brinkmann replied, "I am just uploading a fresh hurd package which should fix all these problems."

 

9. Installing The Hurd From FreeBSD
1 Feb 2000 - 3 Feb 2000 (12 posts) Archive Link: "Install from FreeBSD"
Topics: Bootloaders, FS: ext2
People: Roland McGrathIgor KhavkineDaniel BurrowsR Joseph Wright

R Joseph Wright wanted to install the Hurd from FreeBSD, without installing Linux. Roland McGrath gave this long explanation:

There are two answers to this, both of which are "yes, but you will be the first to test it in recent memory".

To start with, Mach should grok the FreeBSD partitioning ok, so that should not be an issue however you want to do it. I'm not keeping real close track of GRUB, but last I knew it didn't know about the new-fangled freebsd boot-loader configuration crapola, so you might want to just chainload the freebsd boot loader rather than having GRUB boot your freebsd kernel.

I believe current freebsd systems support the ext2fs (Linux) filesystem format. You can either compile e2fsprogs (perhaps it's even in the ports collection, I don't keep track), or maybe run a linux mke2fs binary under freebsd's linux binary emulation, to make a filesystem. If you are doing a tarball install, then I presume you can figure it out from there (i.e. mount the ext2fs filesystem, untar from freebsd, and then pick up the linux-oriented instructions from there). If you want to use cross-install, then you might be able to do that using a dpkg binary under emulation, or compile dpkg yourself for freebsd, but I'm not going to help you figure all that out.

The other answer is that the Hurd supports the ufs/ffs (BSD) filesystem too. (It was the Hurd's first filesystem, in fact.) The bad news here is that the ufs filesystem has not gotten nearly as much maintenance and testing as ext2fs in the last couple of years. The format supported by the Hurd's ufs filesystem is compatible with older BSD filesystems, and last I knew it had no problem with FreeBSD filesystems, but I haven't kept track of the BSD changes in some years and there may well be newer ffs format features that the Hurd doesn't fully support. The good news is that the ufs filesystem has not gotten nearly as much maintenance in the last couple of years, and it was fairly stable before I started breaking everything else. Note that running a BSD fsck on a Hurd ufs is a bad scene, unless you really, really know what you are doing (i.e. use fsck without -p and know when to say y, know when to say n, and know when to run).

Regarding this second approach, Igor Khavkine replied with his experience, "I tried once to install Hurd on a UFS partition, but since I didn't have FreeBSD installed I had to use one of the rescue disks from the 3.0 distribution to make the partition. I was able to unpack the tarball on it, and GRUB was able to boot the gnumach from it. However the ufs.static server failed to recognise the partition. It's possible that I have not created the right type of a UFS partition or that the format was too new. If you can by all means try installing it on a UFS partition (choosing an older format would be best), and maybe report about the stability of the filesystem server."

Although no one replied to this, there was some discussion of how to boot GRUB from the hard drive instead of just a floppy. According to Daniel Burrows, this would be extremely difficult, though possible. He said, "It requires a bit of black magic and the proper incantation using the "install=" command. Even beginning to explain this beast is almost out of the scope of the email; please refer to the Grub documentation :) Basically, though you can install Grub on any block device, in a whole lot of ways (for example, from memory: you can install a minimal amount of stuff on the boot sector and store the rest on the hard drive, or install a subset of the full functionality -- the basic routines plus just one filesystem driver -- on the boot sector)"

Alexander Kellett suggested that someone write up a GRUB HOWTO, since installing it is so difficult. No one volunteered though.

 

10. Hurd Installation Pages
2 Feb 2000 (1 post) Archive Link: "Hurd Install pages"

Muhammad Hussain Yusuf announced his install pages at http://www.memo.cx/gnuhurdguide, and mirrored at http://www.crosswinds.net/~gnuhurd, http://lufog.dhs.org/hurd, and http://www.metanet.org/cryptnet/fsp/hurd/guides. There was no reply.

 

11. Minimal Hardware Requirements For The Hurd
4 Feb 2000 - 5 Feb 2000 (5 posts) Archive Link: "hardware requirements"
People: Tom Cato AmundsenMark KettenisAdam SampsonNiels Moller

Tom Cato Amundsen was going to dig up an old PC to play with the Hurd, and asked, "What do I need of memory and cpu, will an old i486 33 or 66 MHz 16 MB do? When compiling the hurd on such a system, are we talking about hours, days or weeks?"

Mark Kettenis replied, "An i486 should do (as long as it is not an SX), but 16 MB of memory is probably the absolute minimum to do anything "useful" with it. You'll need to resove some disk space for swap though. If you want to do some real development work you'll probably want a more powerful machine. I'm doing serious work on a Pentium 166 with 32 MB of memory. Compiling the Hurd on the Hurd itself takes several hours, the C library in the order of a day (but that includes some reboots). I usually cross-compile from Linux though. So on your i486 it will probably take a couple of days to compile the C library."

Niels Moller and Adam Sampson also pointed out that, since floating point emulation was not working yet, a 486DX or better was a minimum requirement for running the Hurd.

 

 

 

 

 

 

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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.