Diego Roversi had problems cross-compiling the Hurd because of multiple definitions of glibc symbols. Marcus posted a script to fix the absolute symlinks.
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.
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:
What features are provided?
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.
Problems, open issues
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).
Open issues:
- I don't know if and where I need to lock the task or the contained bitmap.
- I don't know if we should put the bitmap directly in the task structure, or wrap it in a generic machine construct like done with threads/pcb.
- I don't protect the bitmap in the task structure with [i386] (see above).
- I use kalloc, and don't deal with resource shortage, but I should.
- I would like to optimize the i386_io_port_modify call to avoid a copy of the whole bitmap if the running task had a bitmap that was copied before. (See #if 0 out'ed code in iopb.c), but this sucks in macros only in pcb.c
- I have not tested NCPU > 1, not even on single-processor machine (eg, I don't even know if it compiles).
- When setting the global descriptor table entry, I use kvtolin for the segment address. Roland didn't do this in the multiprocessor code, a bug? Or am I wrong in doing the conversion?
- To glue the io_port stuff at the device struct, I use my union trick rather than lumping it into union com. I implemented this before Roland told me to go for the simple solution, and kinda like it. But maybe change it back.
- No ChangeLog entry yet! No copyright header on new files!
Status
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).
GNU Mach
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.
Exercise
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:Simplicity. The smallest value we can handle is a bit, and this is the bitmap we have already. However, instead searching for bits that have to be modified, we are simply copying everything right now. I like the idea of only copying 256 bytes instead 8192, but I don't like any more sophisticated segmentation, because this means that one has the overhead of another real bitmap, that needs to be allocated, free'd and maintained. The segment map should fit into a single basic type, like an uint32_t, everything else is overkill IMO.
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.
EOT.
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.