Re: devfs user client, RFC
Re: devfs user client, RFC
- Subject: Re: devfs user client, RFC
- From: Kevin Van Vechten <email@hidden>
- Date: Mon, 19 Nov 2001 19:39:40 -0800
On Thursday, November 15, 2001, at 10:23 AM, Godfrey van der Linden
wrote:
The problem we are trying to solve is to get
open/read/write/ioctl/close access to a /dev/... file. With the
current implementation that means talking to a full on cdevsw entry,
'cause there is just no other alternative.
This morning a thought occurred to me, I propose we change Libc syscall
implemetation to redirect the read/write/ioctl/close calls selected by
fd.
Sounds interesting. I was scared of this when I first read it, but now
after I've thought about it a while it seems like the most reasonable
solution.
Only the open goes directly into the kernel. Then we make the other
cdevsw calls indirect through a pointer to a function in user land
BEFORE taking the syscall trap. This solves all sorts of problems with
getting data from process to process. The redirector will call
functions that implement read/write/ioctl (RWI) on top of the CFPlugIn
model proposed by ChrisS. Remember the the CFPlugIn interface to tapes
and CD etc will already exist as that is MacOSXs preferred solution for
device access of this nature.
Taking this idea, here's how I imagine things:
We'd need an IOKit extension to provide the devfs creation API. Some
application, for example a userland tape driver, would call the creation
routine, and specify the path to a client CFPlugin to handle calls to
the dev node. The IOKit extension would maintain a lookup table of dev
nodes and CFPlugin Paths.
During an 'open' call, Libc would query the IOKit extension to see if
the returned fd is special or not. If it is special, the CFPlugin
associated with it would be loaded (or retained) into the client app's
address space. The future read/write/ioctl calls would be forwarded to
functions in the CFPlugin, which would then do something... for example
communicate with a userland tape driver via mach messages. For a
'close' call, the CFPlugin would be released.
Cons: Requires a small lookup-table that is wired into memory.
Pros: Doesn't require a general devfs daemon, doesn't require buffers
taking a detour though kernel space. Also seems to address many denial
of service or other related concerns, since each plugin would live in
the clients' address space, and there's no central "userland devfs hub"
that might be killed.
Is this what you had in mind?
-Kevin