Clone system call - i/o permissions bitmap not updated

From: Greg Haerr (greg@Censoft.com)
Date: Sat Feb 19 2000 - 15:04:22 EST


I'd like feedback on the following suggestion:

The clone system call should copy the original task i/o permissions bitmap
to the new task when passed the CLONE_VM flag. Currently, the
intent of CLONE_VM is to have parent and child share address spaces,
which includes mmap()'d files. Currently, the LinuxThreads package specifies
CLONE_VM|CLONE_FS|CLONE_FD on thread creation, attempting
to give the new thread all resource access the parent had. But this is not
quite
enough, because the i/o permissions bitmap isn't copied. Perhaps another flag
could be implemented e.g. CLONE_IO for this; I haven't found a way
to inherit the original permissions bitmap.

I'm developing the Microwindows/Nano-X graphics system that uses
Linux framebuffers. We support the all linear framebuffers, but I've just
added support for the VGA16 (planar) fb from 2.3.45 and 2.2.14. The VGA16
framebuffer requires in and out instructions in addition to writing to the
framebuffer. This hadn't been a problem, except I've run into a project
where there's extensive use of LinuxThreads with Microwindows. My
VGA16 fb driver has to execute an ioperm() call to get access permissions
to talk to the VGA. But after a thread create, the new thread doesn't
have access to the VGA anymore, since the i/o permissions are reset.

This can be worked around, by having each thread call a special init
function, but this won't eventually work since ioperm requires root permission,
and eventually we'll want to create new threads after resetting
the process effective id back, and ioperm will fail, so we need the bitmap
at the time of thread creation.

Regards,

Greg

-
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.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:24 EST