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