bug-hurd
[Top][All Lists]
Advanced

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

Re: I/O permission control in OSKit-Mach


From: Roland McGrath
Subject: Re: I/O permission control in OSKit-Mach
Date: Wed, 17 Oct 2001 04:43:55 -0400 (EDT)

> 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.  Anyway, this is not so really bad; tasks that get
ioperm usually keep it.  Linux does the same.  (But with the optimized
implementation I described in my last message, this is moot for the context
switching issue and relevant only for the storage.  It would be acceptable
to do that optimization on the basis of "highest port number ever set", 
and have copying of trailing zero bits for the rest of the life of the task.
If you did keep track of the current highest bit set, then you would know
already right then when you can completely free the bitmap.)

> 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.

> * 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).

> * 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 vote for a `struct machine_task' element in struct task
defined by machine/task.h, like pcb for is struct thread.

> * I use kalloc, and don't deal with resource shortage, but I should.

All the places you need to allocate, there is nothing that makes it
hard to fail gracefully and return an error.

> * 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

Fine, but who cares?  I don't think ioperm needs to be real fast.

> * I have not tested NCPU > 1, not even on single-processor machine (eg, I
>   don't even know if it compiles).

We'll find out eventually.  Just compiling is as good as SMP gets right now.

> * 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.

> * 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.

Whatever floats your boat.

> Roland, can I count on you to take care of the glibc side eventually?

Of course.

> 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.

I don't see a reason to bother, just as you say.


You changed to much code in iopb.c that I'm not sure there is much that
remains.  I am inclined to suggest you just replace it with a new file
(io_perm.c or whatever) instead.  I have generally tried to keep major new
stuff in separate files in oskit-mach, thinking it will make life easier
when doing any merging between gnumach and oskit-mach.

I really don't like a typedef named `iopb'.  There's a reason God invented _t.
(Seems like a useless type anyway.)

I don't like `struct x86_tss_ext' as the name.  Let's try to leave x86_* to
the oskit.  Call it `task_tss' or `task_i386_tss' or something.  Actually
you might as well just open-code it in the i386 `struct machine_task'.



reply via email to

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