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.||30 Sep 1999 - 3 Oct 1999||(7 posts)||Filesystem Corruption And Unrelated Fixes|
|2.||30 Sep 1999 - 4 Oct 1999||(7 posts)||KGI In The Hurd|
|3.||9 Oct 1999 - 10 Oct 1999||(2 posts)||'cross-install' Bugs|
It looks like Issue #17, Section #8 (23 Sep 1999: Confusions Over Translators) credited Stallman with writing the article "Towards a New Strategy of OS Design" (http://www.gnu.org/software/hurd/hurd-paper.html) , while the actual author was Thomas Bushnell. Many, many thanks to OKUJI Yoshinori for pointing this out. Thanks, OKUJI!
Mailing List Stats For This Week
We looked at 51 posts in 174K.
There were 20 different contributors. 13 posted more than once. 0 posted last week too.
The top posters of the week were:
1. Filesystem Corruption And Unrelated Fixes
30 Sep 1999 - 3 Oct 1999 (7 posts) Archive Link: "Re: File system corruption"
Topics: FS: ext2
People: Roland McGrath
In the course of discussing some ext2fs corruption, Roland McGrath made some changes and explained them:
I did fix a bona fide bug in libstore (one introduced by my 1999-09-09 change). This is a bug that would not show up when using a whole disk partition, but only when using something like a noncontiguous file as the store. So, ironically, this is not the bug that has been biting people, but if you made a test filesystem in a file to try to isolate that bug (as I and others have recommended several times), then you are quite likely to have hit this bug. This libstore bug caused reading and writing of the wrong disk blocks, so you would have effectively seen garbage on your disk from it. I am pretty sure that this libstore bug could not have affected any filesystem using a whole disk partition.
I also checked in several changes to ext2fs. The "bad type in directory" problem's fix I already posted. As I said then, I am pretty sure that this bug could not have any bad effects other than producing that warning message.
The other changes are just cleanups that might be slightly beneficial for performance, but I did not find any bugs that they address. (Incidentally, I added support for the --sblock option to use an alternate superblock.)
I did fix the `group_desc' function yesterday (and I think posted that fix separately); it was indeed bogus for filesystem blocksizes other than 1k, and responsible for the "no root inode" panic with such filesystems. But, again, I am pretty sure that this bug would only bite filesystem with a blocksize other than 1k, and since it bit them totally with a panic on startup, you could not have had this problem and not known it.
So, yes, I have fixed some actual bugs. However, for anyone using a whole disk partition who has seen a problem other than "bad type in directory" or "panic: no root inode", then I have not fixed anything that explains any other problems and I suspect they are still lurking there.
Anyone trying to track down filesystem bugs should certainly update to the new code, just to make it easier to keep track of things. But I would expect you to still see the same symptoms if they were not one of the specific cases mentioned above. When you do see a problem, it is important to show me any messages you get as exactly as possible (magic numbers and all). Also, immediately after the crash, run `e2fsck -n' on your filesystem and send me the whole output (if it says anything but "all ok" or "clean flag not set"); it ought to work equally well to run e2fsck from Hurd or Linux. Another thing people might try is recompiling ext2fs with -DEXT2FS_DEBUG, and then start it with -D (or use fsysopts /fs -D to toggle); that should produce some (perhaps voluminous) debugging output while ext2fs runs (I haven't tried this myself). The debugging messages that come out around the time of a crash or data corruption might help me guess where the problem lies.
2. KGI In The Hurd
30 Sep 1999 - 4 Oct 1999 (7 posts) Archive Link: "Porting KGI to the HURD"
People: Steffen Seeger, Marcus Brinkmann, Thomas Bushnell, Kalle Olavi Niemitalo, Brent Fulgham
This topic first came up in Issue #1, Section #10 (28 May 1999: GGI In The Hurd) . This time, Steffen Seeger from the KGI project made his introduction to the list:
Brent Fulgram (I hope I spelled the name right) posted a message on the GGI development list about people working on the HURD OS investigating possibilites to port the KGI framework to HURD and looking for support regarding the technical details of it.
Well, I am the main author of kgi-0.9 and will be available for any questions you may have regarding it. I have not much background about HURD yet, except it is a microkernel OS, and a very interesting project.
I managed to install HURD on my machine, I had a look at the relevant source, but had not yet a chance to dive into the details of it. But I am willing to learn about HURD, helping a bit getting KGI ported if you think this would be worth it.
I have some introductory articles I can post on request. I just don't want to flood you with stuff you don't want to read...
Brent Fulgham posted a URL to Thomas Bushnell's Towards a New Strategy of OS Design (http://www.gnu.org/software/hurd/hurd-paper.html) , and encouraged Steffen to post pointers to his introductory articles as well.
Marcus Brinkmann also welcomed Steffen, adding:
Let me summarize the current situation. We are using the Hurd servers on top of the GNU Mach microkernel. The Hurd is a multi-server OS, and thus quite different from the usual single-server or monolithic kernel OS you can find around every corner.
The Mach has a simple built in console, and some simple built in mouse drivers. In this regard, the mach is not very different to the Linux kernel, for example (except that the Mach console is much more primitive).
The similarity is so strong that we are able to use Linux character devices in GNU Mach with just a little bit of glue code and small changes here and there. (I have spend a few days porting the Linux console to GNU Mach, and it works, but there are still some small problems. It's definitely doable, though). But this situation is contrary to the design goal of the Hurd.
To fix this, we want to have the console code outside the (micro)kernel. Kalle Olavi Niemitalo <firstname.lastname@example.org> started a simple colortext console server that fits better in the Hurd design. It writes directly into the video memory by memory mapping and will receive the scan codes from the keyboard by event mode of the mach keyboard driver. I hope that this server will be completed and gives us a small implementation of a console server for the Hurd soon, and maybe serves as an entry point for further efforts in this direction.
This is where KGI comes in. It sounds as if KGI could provide a full featured terminal server (multihead/multiinput, virtualization of mouse, hooks for libggi library, hence providing a svgalib emulation layer and a X server, I am partly guessing here, please correct me if I am wrong). It also looks as if KGI could be hooked in the Hurd design rather flawlessly, considering that it had to be developed as an independent project from the Linux main stream kernel right from the beginning. I think the first step is for either of us to get a picture of the other projects field of operation, so we have a better picture of where the areas of contact exactly are.
Steffen posted URLs to a general KGI overview (http://www.tu-chemnitz.de/~sse/ggi/KGI-white-paper.txt) and a more detailed explanation of the drivers (http://www.tu-chemnitz.de/~sse/ggi/KGI-display-driver-overview.txt) . He added, "These have been written when presenting KGI to the UDI group. We are very interested in getting KGI using the UDI environment, as it takes a lot of portability burden from KGI. I hope this works out. [I am aware of the political issues involved, but I tend to be pragmatic here. UDI solves a lot of problems involved with writing portable drivers, so from a technical standpoint, I have no reason to reject the good work they've done.]"
There followed an implementation discussion. Looks like the ball is rolling on this one, folks.
3. 'cross-install' Bugs
9 Oct 1999 - 10 Oct 1999 (2 posts) Archive Link: "bug in `cross-install'"
People: Erik Verbruggen, Marcus Brinkmann
Jeff Sheinberg and (under the Subject: Problem booting Hurd after cross-install (http://www.debian.org/Lists-Archives/debian-hurd-9910/msg00060.html) ) Erik Verbruggen both noticed problems with 'cross-install', and Marcus Brinkmann pointed out that 'cross-install' had severe problems. He added that he'd be uploading a new version, just as soon as he could wrestle his upload process into submission.
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.