Re: devfs user client, RFC
Re: devfs user client, RFC
- Subject: Re: devfs user client, RFC
- From: Godfrey van der Linden <email@hidden>
- Date: Thu, 15 Nov 2001 10:23:22 -0800
G'day All,
Just had an interesting idea. I have been bothered by the concept of
a seperate server daemon to serve as a user land adjunct to a specfs
(cdevsw) node. The problem is that I can't see anyway of giving user
land code permission to write in an another tasks address space and
THAT sort of power is very scary indeed. The alternative is to copy
potentially vast amounts of data from client/kernel/server/kernel,
expensive.
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.
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.
Am I going to die? Please be gentle with me in your responses.
Godfrey