> I don't know yet enough. It's okay to not fix the broken code and put the > new implementation there immediately, but I would like to have at least an > idea why the code doesn't work "as is".
I won't discourage you from working on it. But I've always found debugging this stuff to be pretty aggravating. > BTW, can we avoid copying the bitmap if we switch from one thread to another > thread in the same task? Of course. That's what I meant when I described how to make it task-based. Look at the places switch_ktss is called. Right before that, is the pmap switching done only if the task is changing; we'd do the io bitmap there too. > Or, a related question, when does a change in the bitmap become > effective, immediately or at the next switch to the thread? This is a > part of the current implementation I don't see. Linux simply diddles the > task (thread?! [1]) bitmap and the kernel tss at the same time. In the current implementation, it diddles them at the same time too--because they are both the same memory. The only place a bitmap is stored is in the io_tss. If the current thread is the one being diddled, that io_tss is the memory that the USER_TSS segment points at. What is really tricky is how the newly-allocated tss gets switched to when the current thread is the one getting a bitmap for the first time. You don't see it happen in iopb.c because it doesn't! If there is a context switch to another thread and back to that one, then it will be set. But if there is no context switch before the first io instruction that thread tries, that instruction will trap. Then it gets to emulate_io, which calls switch_ktss. (This is also where the insane automatic io access if your task has some send right feature is implemented.) However, it doesn't look like emulate_io will actually dtrt if you don't have the iopl device port, but almost. There is no reason for it to be that way. It ought to do switch_ktss after allocating a new io_tss for the current thread. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
