Re: devfs user client
Re: devfs user client
- Subject: Re: devfs user client
- From: Godfrey van der Linden <email@hidden>
- Date: Fri, 9 Nov 2001 15:41:41 -0800
G'day Kevin,
First thing I note is that callbacks just "ain't" gonna work.
We should recognise that the other end of the /dev/... device is
going to be a server out in user land. This server has a thread that
is dedicated to behaving like a driver. It is this thread that will
recieve notifications when completion routines need to be run.
The memory stuff does bare some thought. What would be ideal is if
we don't even move the data out into user land in the first place.
All we move out is a handle that can be passed back into the kernel
and translated into user land memory again. I believe that
vm_map_copy{in,out} may come to our rescue here.
Resource limitation could be achieved by allocating 'struct buf'
equivalents that are setup on a per devfs level. Say 8 or 16 I/Os in
flight per device or per client & device?
Did any of this make any sense? I'm afraid that I can probably give
architectural advice (hey advice is cheap, especially mine). The
problem is that for the next 5 weeks I'm snowed under with MacWorld
deliverables then I'm going home to Australia for a month .
Godfrey
At 13:53 -0800 01-11-9, Kevin Van Vechten wrote:
Hello Godfrey,
I'm hoping to resurrect discussion about a devfs user client.
The initial steps don't look too bad: make a IODevfs extension which
can modify devfs and a IODevfsUserClient which issues requests to
the extension.
Things get trickier with the bdevsw and cdevsw callbacks. It would
be nice to provide a fairly-high bandwidth mechanism for moving
blocks between the kernel and user land. Also it seems like care
should be taken to help prevent a user process from bogging down the
kernel.
When the callbacks are invoked should they send a mach message
describing the event to the user process? The messages could be
handled in code provided by the IODevfsUserClient, which would
interpret the messages and then make calls into the user process
similar to the bdevsw and cdevsw callbacks, maybe even identically,
which would allow for easy porting.
What are your current thoughts on how to implement the bdevsw and
cdevsw callbacks?
Thanks,
Kevin