[Top][All Lists]

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

Re: I/O permission control in OSKit-Mach

From: Marcus Brinkmann
Subject: Re: I/O permission control in OSKit-Mach
Date: Thu, 18 Oct 2001 13:57:33 +0200
User-agent: Mutt/1.3.22i

On Wed, Oct 17, 2001 at 04:43:55AM -0400, Roland McGrath wrote:
> > 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.
> All bits clear you mean. 

Actually, I mean all bits set, as no permission is denoted by a 1 in the
bitmap (that's why the barrier is 0xff, I guess).

I think keeping the bitmap around at the risk that it is not used anymore is
better than the risk that io_permissions are often switched and you end up
allocatin and freeing often.  For both cases it is true that they probably
never will happen.
> > 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).
> I'm not sure what Linux you are looking at (I'm reading 2.4.3 sources).
> What I see is that is copies only 1024 bits (32 bytes) for ioperm.  To
> access the io ports above 1023 you have to call iopl to just run at IOPL0.

In German you would say that I have tomatoes on my eyes. ;)
> > * I don't know if and where I need to lock the task or the contained bitmap.
> Mach is nonpreemptive.  You only need to do SMP locking (simple_lock).

Mmh.  What about i386_io_perm_modify vs. task_terminate on SMP?  I don't want to
scribble in deallocated pages.  Also, what about i386_io_perm_modify vs
another cpu switching to another thread in the same task?  The bad kinds of
interactions I am worried about is not so much the io_perm interface with
itself, but with task_terminate on the one hand and the scheduler on the
other hand.  Do I use a simple lock in the machine_task and make them all
use it?

> > * 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?
> I think that was a bug in code that had never been run, and your fix is right.

It was only used for SMP.  BTW, I did not fix it for your code in my patch,
but will d os.
All other suggestions will also be picked up by me.
Thanks a lot for the input,

`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org

reply via email to

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