bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TSS switching


From: Marcus Brinkmann
Subject: Re: TSS switching
Date: Thu, 11 Oct 2001 00:24:04 +0200
User-agent: Mutt/1.3.22i

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 brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]