Mach 4 (http://www.cs.utah.edu/projects/flux/mach4/html/) | Hurd Servers (http://www.gnu.org/software/hurd/hurd.html) | Debian Hurd Home (http://www.gnu.org/software/hurd/debian-gnu-hurd.html) | Debian Hurd FAQ (http://www.debian.org/ports/hurd/hurd-faq) | debian-hurd List Archives (http://lists.debian.org/#debian-hurd) | bug-hurd List Archives (http://mail.gnu.org/pipermail/bug-hurd/) | help-hurd List Archive (http://mail.gnu.org/pipermail/help-hurd/) | Hurd Reference Manual (http://www.gnu.org/software/hurd/reference-manual.html) | Hurd Installation Guide (http://pick.sel.cam.ac.uk/~mcv21/hurd.html) | Cross-Compiling GNUMach (http://pages.hotbot.com/sf/igorkh/gnumach-cross.txt) | Hurd Hardware Compatibility Guide (http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html)
Table Of Contents
|1.||19 Oct 2001 - 21 Oct 2001||(4 posts)||Error Cross-compiling The Hurd|
|2.||22 Oct 2001 - 23 Oct 2001||(15 posts)||H1 Images|
|3.||15 Oct 2001 - 21 Oct 2001||(19 posts)||I/O Permission Control In OSKit-Mach|
|4.||24 Oct 2001 - 25 Oct 2001||(8 posts)||Diagnosing Hanging ps|
1. Error Cross-compiling The Hurd
19 Oct 2001 - 21 Oct 2001 (4 posts) Archive Link: "error compiling hurd"
People: Diego Roversi
Diego Roversi had problems cross-compiling the Hurd because of multiple definitions of glibc symbols. Marcus posted a script to fix the absolute symlinks.
2. H1 Images
22 Oct 2001 - 23 Oct 2001 (15 posts) Archive Link: "H1 images - comments and questions."
People: Thierry Laronde, Philip Charles
Philip Charles is preparing a new set of CDs for release some time in december. Currently, Phil's CDs that Phil boot into linux using a ramdisk and this is used to partition and unpack the tarball. The Hurd is only started after the reboot. Thierry Laronde said that he was working on booting grub+gnumach+hurd instead of using linux, but that porting Debian boot-floppies was non-trivial. Thierry went on to explain:
I don't think the major problem is a policy one, just a practical one: boot-floppies are one part of the stuff that delayed the release of woody, and probably people working on them will not be fond of changing it now. There is also probably a size problem on 1.44 or 2.88 images, since GRUB is larger than Lilo in size.
One solution would be to allow the use of GRUB at least on HD emulation for El Torito, so that HURD could use the bootstrapping procedures of Debian its own way, that is to add the ability to use GRUB for non size limited images. So this would not break anything for others, but just add alternatives.
Phil discussed the use of "popularity-contest" to decide which packages go on which CDs: "It would be useful long term. Debian-cd puts the base and important packages onto the CDs first, then the packages in the various tasks and then falls back onto popularity contest. IIRC, popularity-contest starts working about the time the first CD is full. I found that some desirable packages were not on the first CD and so thought it time to develop some Hurdish equivalent of task packages. The more of these the better. "
3. I/O Permission Control In OSKit-Mach
15 Oct 2001 - 21 Oct 2001 (19 posts) Archive Link: "I/O permission control in OSKit-Mach"
People: Marcus Brinkmann, Roland McGrath, Kevin Kreamer
Marcus Brinkmann posted a patch to implement I/O permission control in OSKit-Mach by creating the routines i386_io_perm_create() and i386_io_perm_modify(). He gave the following information:
I/O permissions are task based, rather than thread based. All threads will get permission instantly.
The io_perm_t ports represent the capability to control the permission to access I/O ports. A server running as root could hand out permission to access linear port ranges for specific purposes to non-root users (like console users to program the console).
Applications accessing I/O ports written for GNU/Linux will be able to compile on the Hurd without changes, as soon as glibc is extended to cover the new interfaces (see below).
The task switching mechanism will only use one TSS for processors. I/O permission bit maps are edited in place.
There are some details about the implementation which are not ideal, but ok: Once a task gets a bitmap, it is never destroyed, even if no I/O ports are enabled (all bits set). The bitmap is destroyed only with the task.
A task requesting some I/O permission will get a full blown 8192 bytes large bitmap, which is copied in the processor TSS at every switch to the task. (Linux by default only uses a half bitmap, and provides a full one at request by calling a special function -- not ideal either, interface-wise).
Although this is a lot of things to look out for, the patch seems to work at least on single user systems with only one single-threaded program running (eg, avoid problems due to missing locks).
For GNU Mach, a kernel object would be necessary, so that a no senders notification can be sent and the capability be destroyed. No magic, but annoying because it would be a bit different from the OSKit Mach implementation (nothing visible to the outside). I don't plan to "backport" this change to GNU Mach currently, as it seems a usable OSKit Mach (with user space console) is coming along nicely.
Reimplement Kalles cursor move test program so that it works on OSKit-Mach with the patch.
Adam Olsen expressed some concern about how copying 8192 bytes would be expensive and that more than likely usually only a small fraction of the bitmap would be needed. Adam said that he could not think of a reason why there should be segments larger thatn the smallest necessary value.Marcus responded to this:
And also Roland commented:
If copying it all every time is good enough for Linux, it's good enough for us.
You can change the bitmap offset in the TSS with little cost, so you can always use a smaller bitmap stored at the tail end of the TSS segment. For each task, keep track of the highest port number whose bit is set. At task switch, copy only that number of bits into the tail end of the TSS segment, and reset the TSS io bitmap slot to start that many bits back (actually you have to round this all to bytes).
Linux could be said to do the limiting case of this, since it always either sets the offset at the end of the segment and copies no bits, or always copies exactly 1024 bits. That's what you'll get here for a bitmap-less task and a task using port 0x3ff.
There was some discussion about what to do about modifying permissions (i386_io_perm_modify) as another cpu switches to a different thread in the same task. Marcus was worried, in this case, about interactions of task_terminate and the scheduler. He pondered the idea of a (simple) lock in the machine_task and make the others use that.
Roland thought that that would do for now, but said: "Needs some more though. Stick in an XXX comment or a #warning #if NCPUS>1 and we can think about it again when working on making SMP really work."
Things settled down and Kevin Kreamer did indeed reimplement Kalles' cursor move program.
4. Diagnosing Hanging ps
24 Oct 2001 - 25 Oct 2001 (8 posts) Archive Link: "ps just hangs"
People: Roland McGrath, Mark Kettenis, Jeff Bailey
Jeff Bailey was having a problem in that his ps hung as a normal user. As root, he could run ps, but not ps -ef. Roland McGrath advised him: "Whenever ps hangs, try ps -M and then narrow down if it hangs only querying specific processes without -M" . Jeff did this and found it was inded the case. Roland further advised: "you need to attach to that process and figure out what it's trouble is. First you can do ps -M --threads 743 to see what you can see about its threads. There should be two. The second one is the signal thread, and if it is halted or something then that is bad. With gdb, you can see what this thread is doing and why it doesn't properly handle the message port RPCs."
So Jeff attached his gdb to the problem process (/usr/bin/tail) but found that he could not interupt.
Roland did not like this, saying "there is no excuse for C-c not working in gdb. Someone should debug gdb. "
Mark Kettenis and Roland agreed that interupt failing was because gdb was trying to talk to the signal thread, Mark adding " C-c is supposed to interrupt the program, which obviously fails because the signal thread isn't responding. Should it interrupt GDB instead in such a case?"
Roland said that when using "attach" in gdb, the C-c should only ever go to gdb.
Mark noted that "set noninvasive on" should be executed before attaching to a process.
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.