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
|1.||29 Jul 1999 - 8 Aug 1999||(9 posts)||Log Based Filesystem|
|2.||5 Aug 1999 - 11 Jun 1999||(13 posts)||Hurd On SCSI; Modules With Hurd; Porting Hurd To Non-Mach Micro-Kernel|
|3.||6 Aug 1999 - 9 Aug 1999||(6 posts)||Grub Problem And Fix For Locking Machine And Failing Passwords|
|4.||7 Aug 1999||(1 post)||Inetutils Update|
|5.||7 Aug 1999 - 8 Aug 1999||(3 posts)||Cross Compiling gnumach|
|6.||9 Aug 1999 - 10 Aug 1999||(4 posts)||X Under The Hurd|
|7.||9 Aug 1999||(2 posts)||Vacation|
Mailing List Stats For This Week
We looked at 86 posts in 210K.
There were 32 different contributors. 18 posted more than once. 9 posted last week too.
The top posters of the week were:
Log Based Filesystem
29 Jul 1999 - 8 Aug 1999 (9 posts) Subject: "log based filesystems"
People: Paul Emsley, Mark Kettenis
Mark Kolb asked if Hurd 0.3 might have a log-based filesystem. Paul Emsley gave a pointer to http://www.complang.tuwien.ac.at/czezatke/dtfspapers.html, and Mark Kettenis said such a thing was very unlikely unless a volunteer turned up.
Hurd On SCSI; Modules With Hurd; Porting Hurd To Non-Mach Micro-Kernel
5 Aug 1999 - 11 Jun 1999 (13 posts) Subject: "does the HURD run on this hardware?"
People: Marcus Brinkmann, Aymeric Vincent, Thomas Bushnell, Igor Khavkine, Gordon Matzigkeit
Eberhard Burr had an AMD K6 processor, a Matrox Millennium II video which he could replace with an S3 986 based card if need be, and an IBM harddisk on an Asus SC 200 (NCR 810 based) controller; and wanted to know if he could get the Hurd up on it. Marcus Brinkmann gave a link to http://www.debian.org/ports/hurd/hurd-install, adding that it had a link to the Hardware Compatibility page.
Marcus also replied, "The SCSI controller will be a problem. This is NCR53C8XX right? This driver is not included in the binary distributed kernel, because it breaks non-SCSI systems. You would have to compile your own kernel. Chicken and egg problem." He offered to compile a custom kernel after getting back from his holiday. He concluded with, "GNU Mach has the same scsi and hard disk drivers as 2.0.36, so if you are running Linux, GNU Mach can probably run, too."
Igor Khavkine gave a pointer to his Easy Guide To Cross-Compiling GNUMach (http://pages.hotbot.com/sf/igorkh/gnumach-cross.txt) and asked for comments and questions. Marcus replied with the following alternative method, which he said was much easier:
For Debian systems, there are packages i386-gnu-gcc (a cross compiler!) and i386-gnu-mig (a cross mig!). For other i386 systems, there is make-cross by ordon.
Binutils: Any usual binutils should work, at least if you have a i386 system. The linux binutils binary can process Hurd object files etc. It is sufficient to create links /usr/bin/ld -> /usr/bin/i386-gnu-ld etc.
Header files: If you install the Hurd using cross-install, you can use:cd /gnu ./dpkg-hurd -i /somewhere/gnumach-dev_*deb ./dpkg-hurd -i /somewhere/hurd-dev_*deb ./dpkg-hurd -i /somewhere/libc0.2-dev_*deb
Then you don't need the glibc sources! You don't need the gcc sources if you use the i386-gnu-gcc Debian package or the "make-cross" script by Gordon Matzigkeit. You don't need the binutils sources on a i386 (see above).
Eberhard (the original poster) replied that the situation looked a bit too adventurous. He thought he'd wait until later in the year, and then drop an IDE drive in the box to make it easier.
In the course of discussion, it came up that gnumach would probably never support modules. Igor asked why this was, adding that he didn't think it would be very difficult to implement. Aymeric Vincent explained:
GNUMach is a weird piece of software, because its development is ``layered''. Each time the development team changed, some part of the philosophy/coding habits changed. For example, there are two kinds of drivers that coexist in GNUMach: original Mach drivers (almost deprecated on the i386), and Linux drivers. I don't know if it would be easy to put both into modules.
I think the main reason is that no one really wants to improve GNUMach too much. It seems that the policy is to maintain it (i.e.: add new drivers, fix bugs), but not to improve it. However, anyone willing to do so is certainly welcome :)
BTW, could someone (Thomas, Roland, Okuji?) tell us what the ``official'' policy is, concerning GNUMach? I'm still porting GNUMach to the m68k when I have time, but the more it goes, the less it seems useful... I'd very much like to see the HURD run on some other architecture, but I'm not sure porting GNUMach is the best way, seen the poor support it gets... Should I try to do something about libmom instead, or is this currently a dead end?
Thomas Bushnell made an interesting revelation:
I'm not sure at all what the best strategy is, but here's some data points that might help.
All the core hurd hackers are interested in switching to another kernel. Once we make a fairly stable release, one of our priorities will be excising as many Mach-dependencies from the Hurd and libc as we can. I have a fairly good idea about how to go about this; I don't think it will negatively impact performance, but the current libmom is basically three-generations of thinking ago on this. It does not reflect any longer the direction we will go as far as practical implementation techniques.
Once that's done, the next step is to find a suitable kernel and port to it. There are several candidates, but I have no interest in commiting now since the space of candidates may shift considerably when we are ready to switch.
If we do the kernel-independency work well enough, it might be so cheap to run on multiple kernels that we can simultaneously support several options. I don't know.
Grub Problem And Fix For Locking Machine And Failing Passwords
6 Aug 1999 - 9 Aug 1999 (6 posts) Subject: "GRUB 0.5.92 problem"
People: OKUJI Yoshinori
Mark Lundeberg compiled (from RedHat 5.1) and installed the latest version of Grub, which proceeded to hard-lock at bootup and wipe his CMOS. OKUJI Yoshinori thought RedHat's binutils might be old and buggy. Mark replied that this seemed to be it, and upgrading from binutils 184.108.40.206.4 to 220.127.116.11.25 made the difference.
Without the lockups, Mark noticed a new problem: trying to get passwords working with Grub would give a "Failed!" message each time. OKUJI was happy for that report and posted a patch. Mark reported success (but posted his own mini patch to OKUJI's patch), and OKUJI said he'd apply it.
7 Aug 1999 (1 post) Subject: "new inetutils package with better syslogd"
People: Marcus Brinkmann
Marcus Brinkmann announced:
I uploaded inetutils 1.3.2-6, which will hit the archive in a day or so.
This is the best inetutils ever :)
I updated syslogd to understand all the nifty additions from the Linux config file format, so you can use the same config file as under Linux (or at least similar. We don't have xconsoles, virtual consoles and such).
I also did implement many other changes that I found in the Linux syslogd. I am in contact with the maintainer of inetutils about getting this changes in the upstream source.
There are still some major features missing from the linux version (unix domain sockets and other network stuff), but then we have a much nicer glibc integration and no limits on hostname lengths etc. It's a draw :)
(Another story is the kernel logger, we need to work on this, too, but I am not sure what is involved. Any tips from our mighty heros?)
A complete list of changes can be found below.
And yes, if you install this package, syslogd WILL stop complaining at start up.
Someone cares to syslogify the Hurd now?
Cross Compiling gnumach
7 Aug 1999 - 8 Aug 1999 (3 posts) Subject: "Problems cross-compiling gnumach"
People: Marcus Brinkmann, OKUJI Yoshinori
Pablo Baena had never been successful at cross-compiling gnumach, and this time didn't look to be any exception. This time he was getting a
make: *** [clib-routines.o] Error 1
error, and OKUJI Yoshinori said the problem was with the cross compiler being unable to locate libc.a anywhere. Marcus Brinkmann agreed, and added:
here is a simple way to fix this. Create a Hurd partition, and get the Debian Hurd packages of libc0.2, libc0.2-dev, hurd-dev, hurd, gnumach-dev.
Then mount your Hurd part under /gnu (or wherever /usr/i386-gnu/lib and include point to) and extract the content of the packages. If you don't have Dbeian and thus can't use the dpkg-hurd script (do you have dpkg installed on your FeeeBSD system?), then you can do so withar x data.tar.gz packagename.deb tar xzf data.tar.gz
Do this for each package, and then i386-gnu-gcc should work. If you can cross-coompile a GNU Mach, this would be great, because I am not sure I will manage to do a lean GNU Mach before I leave for holiday (sorry).
X Under The Hurd
9 Aug 1999 - 10 Aug 1999 (4 posts) Subject: "Anyone running X?"
People: Gordon Matzigkeit, Marcus Brinkmann, OKUJI Yoshinori
Peter Cejchan was curious if X was working with the Hurd. He had tried to cobble something together with a Linux server, but it hadn't recognized his keyboard. Gordon Matzigkeit said no one had made any X server .deb files yet, and added, "UCHIYAMA Yasushi is the X11 expert here, but I do not know the status of his work."
Marcus Brinkmann felt that something could be done, involving patching and recompiling the Hurd. He added:
This is not a trivial undertaking, and I recommend everyone who does not really mean to do some Hurd and GNU mach hacking to stay with the clients, libs and a remote display. This is tested and works.
The problem is that Okuji has stalled development of gnumach-char, IIRC. This is the only correct way to get a functional X server in the next time. There is little to do on the X side, but quite some work on the GNU mach and a little on the Hurd side (streamdev translator, also by Okuji).
OKUJI Yoshinori replied:
I'm sorry, but GRUB is a top priority for me (if you see the amount of patches and bug reports for GRUB, you can understand what I mean). The character devices support is desirable, but personally I think bootstrap is much more important.
If someone would like to takes over my work on gnumach-char, I appreciate him/her. I was working on it, and thought that it would be easier to use OSKit than to develop our own framework. So I recommend him/her to see OSKit before working on it actually. All of my snapshots can be found in alpha.gnu.org:/gnu/hurd/contrib/okuji/ (ftp://alpha.gnu.org/gnu/hurd/contrib/okuji/) .
9 Aug 1999 (2 posts) Subject: "no activity from me the next two weeks"
People: Marcus Brinkmann, Gordon Matzigkeit
Marcus Brinkmann announced that he was going away for two weeks, and Gordon Matzigkeit wished him a good vacation.
Under the Subject: native-install needs updating () , Marcus replied, "PS: Thanks Gordon, I will. Danmark is a nice place to waste some time. PPS: Now I am really away :) PPPS: Don't think I write something funny here."
We Hope You Enjoy Hurd Traffic
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.