Re: devfs user client
Re: devfs user client
- Subject: Re: devfs user client
- From: Kevin Van Vechten <email@hidden>
- Date: Fri, 9 Nov 2001 16:15:32 -0800
Hello Godfrey,
Thanks for the quick reply. As a note, in my first email I think I was
using the term "callback" too loosely (as a concept not an
implementation). Your reply made sense. I like the idea of notifying
the user process with a token, and then letting the process call back
into the userclient with the token to get at the data.
vm_map_copy{in,out} looks like it will do the job.
What mechanism should be used to notify the user process of activity on
the devfs entry? Could I use an IONotificationPort for that?
Thanks,
Kevin
On Friday, November 9, 2001, at 03:41 PM, Godfrey van der Linden wrote:
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