Subject: Re: Querying an userland program from the kernel
To: Bill Studenmund <firstname.lastname@example.org>
From: Stephan Uphoff <email@example.com>
Date: 01/26/2004 15:56:46
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
}:-) (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
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 }:-)