On Mon, Oct 08, 2001 at 07:34:25PM -0400, Roland McGrath wrote: > (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.
I guess we will drop the automatic io access entirely? I don't see the value of it because you can just give a task the necessary permission if needed beforehand. Or am I overlooking somehing (like DOS emulation or whatever)? Can I/O permission violations be catched in userspace, by emulating the io_emulate exception? Then I guess we can just let the default implementation return an error anyway. > 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. Well, in the new scheme we just check if the task to be manipulated is the current task, and update the bitmap in the TSS in this case (along with the task bitmap). We have a global lock for all the iopb mess. Actually, I think after removing all the user space TSS and IO port list stuff, it's only the device<->io_port_t lookup, the task bitmap and the ktss manipulation that needs to be locked (the ktss manipulation when updating the current tasks permissions, not when being in a task switch). I am right now using the global lock exclusively, though. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
