Date: Thu, 9 Nov 1995 05:36:49 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: ioctl() question... Message-ID: <199511081836.FAA05048@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>struct buf
>{
> u_short count, timeout, status;
> u_short data[256];
>}
>#define GETSTUFF _IOR('p', 15, struct buf)
>#define PUTSTUFF _IOW('p', 16, struct buf)
>#define PUTSTATUS _IOR('p', 17, int)
>Where PUTSTATUS gets the status of the last put operation. This is
>yucko and non-orthagonal, and I'd prefer to do
>#define PUTSTUFF _IOWR('p', 16, struct buf)
>but I'm ignorant of the relative merits wrt copyin/copyout time vs.
>syscall time.
_IOWR() copies the data both ways whether it is used or not, so it is
not good to use it if the data is large and mostly not used in one
direction.
>It's also possible that the data[] array may grow, although I'm trading
>off against read/write with that 8(
ioctls aren't well suited to copying variable amounts of data. It's
simplest to put the data in the ioctl buffer so that it is copied
automatically, but then the ioctl buffer has to be large enough to
handle the largest desired amount of data. A few drivers (surprisingly
few) pass pointers to data and call copyin/copyout directly. In some
cases this is obviously because they were NIH. E.g., the speaker
driver copyin's a tiny amount of data that could easily be passed
directly.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511081836.FAA05048>