From owner-freebsd-hackers Wed Nov 8 10:37:07 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA13511 for hackers-outgoing; Wed, 8 Nov 1995 10:37:07 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA13505 for ; Wed, 8 Nov 1995 10:37:04 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA05048; Thu, 9 Nov 1995 05:36:49 +1100 Date: Thu, 9 Nov 1995 05:36:49 +1100 From: Bruce Evans Message-Id: <199511081836.FAA05048@godzilla.zeta.org.au> To: hackers@freebsd.org, msmith@atrad.adelaide.edu.au Subject: Re: ioctl() question... Sender: owner-hackers@freebsd.org Precedence: bulk >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