Hi,

Bill Studenmund wrote: 
> When I was at NASA working on the HSM, we used our own device driver
> (which you need for ioctl to work), and just left userland in read(2).
> Nices things about read() as opposed to ioctl() are: 1) you can use
> select(2)/kevent(2), 

}:-) (evil grin) 
What exactly prevents (mis-)using  select(2)/kevent(2) to detect when the
ioctl would not block ...

> and 2) you can easily handle variable-sized RPC
> requests. Yes, you have to provide the syscall the same size userland
> buffer in each case, but read(2) will only transfer what's there, whereas
> ioctl(2) will always transfer a fixed amount of data. If you are doing RPC
> that may be as large as 8k but often is much smaller, this size difference
> may matter.

There is no real reason to put all the data in the main ioctl structure.
( Unless you are programming Solaris Streams Drivers ...)
Just put pointers to user space buffer in the main structure and 
copyin/copyout the bytes that you want. 

You can copy bytes to/from user space in the same ioctl - something
that would require two system calls with read/write.

I have to admit that reading/writing using a device driver or socket (as 
mentioned
by "der Mouse") is a lot more aesthetic.

But an ioctl gives you (almost?) the power of a system call.

Hey .. anyone mentioned shared user-mapped kernel memory yet  }:-)

	Stephan