> Now this means that the kernel *could* be modified such that the I/O
> bitmap is not allocated at all by default for a task, and the
> allocation of the I/O bitmap is staved off until a task calls the
> ioperm() system call. [...]
the problem is that the ->iomap pointer within the TSS is only 16 bits :(
This means we'd have to allocate the bitmap within 64k of the address of
the (already allocated) task structure. It's highly unlikely that this can
be done cleanly :( Maybe we could 'relocate' the task, but this is way too
much work and complexity, as all possible data structures that somehow
might reference this task have to be fixed up.
a better solution is to add a new CLONE_ flag, which says that the new
task should have an 8k IO bitmap. (this is quite easy, we just have to
allocate 4 pages when creating the new task, instead of the current 2)
there is a cleanliness issue here though, this really does not belong to
CLONE_ flags, but i have no better idea how to tell the kernel that we
need an 8k bitmap for that given task ...
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html