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