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.||5 Dec 1999 - 8 Dec 1999||(13 posts)||Newcomer Problems And Solutions|
|2.||6 Dec 1999 - 9 Dec 1999||(6 posts)||Perl-Based Translator|
|3.||6 Dec 1999 - 8 Dec 1999||(4 posts)||/proc Under The Hurd|
Mailing List Stats For This Week
We looked at 55 posts in 144K.
There were 24 different contributors. 8 posted more than once. 6 posted last week too.
The top posters of the week were:
Newcomer Problems And Solutions
5 Dec 1999 - 8 Dec 1999 (13 posts) Archive Link: "From GNU/Linux to GNU/Hurd"
People: Adam Sampson, Marcus Brinkmann
Wolfgang Jehrling wanted to install the Hurd on his 486, but because the box only had a 200 meg partition, he wanted to use the entire disk for the Hurd, and leave none for Linux. He asked if there was any way to do this, and Adam Sampson recommended putting the disk in another machine and installing from there, then replacing it when the install was complete. Wolfgang posted later, saying that he planned to boot tomsrtbt, and install the Hurd from there.
The following day, under the Subject: It works :-) (http://www.debian.org/Lists-Archives/debian-hurd-9912/msg00035.html) , Wolfgang reported that unfortunately, the hard drive on his 486 was damaged and would never run the Hurd. However, he had successfully installed the Hurd on his Pentium system instead. He reported the problems he'd run into:
First, Wolfgang suffered from the "every keypress must be made twice" syndrome, which went away after an initial reboot. Marcus Brinkmann replied that yes, a reboot after running 'native-install' was recommended. Wolfgang had also had some trouble working with 'ae', and mentioned that he hoped 'vim' worked with the Hurd. Marcus replied that it did, but was not yet fully uptodate in the archives. He recommended 'nvi' until an updated 'vim' became available. Wolfgang also complained that the Hurd used a US keymap, which did not correspond to his keyboard. He asked if there were any way around this, and Marcus gave a link to a hack (ftp://alpha.gnu.org/gnu/hurd/contrib/marcus/keymap.tar.gz) that would work.
6 Dec 1999 - 9 Dec 1999 (6 posts) Archive Link: "Perl support, concept proved"
People: John Tobey, Daniel Burrows, Kalle Olavi Niemitalo
John Tobey gave a link to his perl bindings for the Hurd libraries (http://john-edwin-tobey.org/Hurd/Hurd-0.01.tar.gz) , announcing, "Friends, I'm pleased to report what I believe to be the first Hurd translator written entirely in Perl. :-) This is the first (pre-)alpha version of what I expect to become a full-featured set of Perl bindings for the Hurd libraries." He gave installation instructions:
tar xzf Hurd-0.01.tar.gz
perl -MHurd::Trans::Hello -e0 -- --help
settrans -ac hello /bin/perl -MHurd::Trans::Hello -e0
Kalle Olavi Niemitalo gave a pointer to the Perl filesystem for Linux (http://www.assurdo.com/perlfs/) and suggested that John write a compatibility module to allow people to use perlfs filesystems under the Hurd, via his library. John was excited to hear about this, and said he'd look into it. Elsewhere, Daniel Burrows mock-threatened to write python bindings. John loved the idea, and suggested that basing their bindings on a common wrapper would be good in the long run.
/proc Under The Hurd
6 Dec 1999 - 8 Dec 1999 (4 posts) Archive Link: "/proc fs implementation under hurd"
Topics: FS: procfs, POSIX
People: Roland McGrath, Marcus Brinkmann
Seth Hutchins noticed that an empty /proc directory existed under the Hurd. He asked if this meant there were plans to support it eventually. Roland McGrath and Marcus Brinkmann both replied that there were no plans to implement /proc under the Hurd, and that it was essentially a legacy Linuxism that would disappear eventually. Roland also offered this advice:
There are no particular plans to implement a /proc filesystem. If you would like to write one, more power to you.
Indeed, "translator" and "filesystem" are somewhat interchangeable terms in the Hurd and what you would be writing is certainly a translator.
To start with, you need get a feel for writing a translator. The files trans/hello.c and trans/hello-mt.c in the Hurd sources are trivial "hello world" translators (a single-threaded version and a multi-threaded) to give you a start at the basic idea. There is substantially more work (and less code to easily guide you) involved in a translator that provides directories rather than a single file node.
The other aspects of the work are how you get at all the information you might want. This information (what is "process state" in Linux) is divided into four pieces in the Hurd: virtual memory, threads, and POSIX process state maintained in the proc server, and POSIX process state maintained in each process by the C library.
The virtual memory and threads are provided by the Mach microkernel, and along with the IPC state, these form a Mach task. (There is a one-to-one correspondence between Mach tasks and Hurd processes.)
The `vminfo' program (source in utils/vminfo.c) will give you a feel for what a process's virtual memory state looks like. The job of providing a mappable file interface for a task's address space is already done by the `task' store type (source in libstore/task.c), which would be used by a translator like storeio; but I don't think that has really been tested, so it might be broken. Anyway, that's about the least complicated piece of the puzzle (in that it's a whole huge world of complication that is already mostly handled elsewhere).
All of the other information I mentioned is already accessed by `ps', and the code that does that is in the `libps' library. You might want to just use that, depending what you want to do with all the information. Reading that library should give you an idea where all the pieces come from and how they are acquired. (Run ps with different options and format strings on various processes to get a feel for what each datum means, and then go look in the libps source code to see what the data structure for that looks like and how libps finds the information.)
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.