Date: Thu, 1 Apr 2010 16:21:35 +0000 (UTC) From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/sys ioccom.h Message-ID: <201004011621.o31GLkU5074268@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
pjd 2010-04-01 16:21:35 UTC
FreeBSD src repository
Modified files:
sys/sys ioccom.h
Log:
SVN rev 206051 on 2010-04-01 16:21:35Z by pjd
IOCPARM_MAX defines maximum size of a structure that can be passed
directly to ioctl(2). Because of how ioctl command is build using _IO*()
macros we have only 13 bits to encode structure size. So the structure
can be up to 8kB-1.
Currently we define IOCPARM_MAX as PAGE_SIZE.
This is IMHO wrong for three main reasons:
1. It is confusing on archs with page size larger than 8kB (not really
sure if we support such archs (sparc64?)), as even if PAGE_SIZE is
bigger than 8kB, we won't be able to encode anything larger in ioctl
command.
2. It is a waste. Why the structure can be only 4kB on most archs if we
have 13 bits dedicated for that, not 12?
3. It shouldn't depend on architecture and page size. My ioctl command
can work on one arch, but can't on the other?
Increase IOCPARM_MAX to 8kB and make it independed of PAGE_SIZE and
architecture it is compiled for. This allows to use all the bits on all the
archs for size. Note that this doesn't mean we will copy more on every ioctl(2)
call. No. We still copyin(9)/copyout(9) only exact number of bytes encoded in
ioctl command.
Practical use for this change is ZFS. zfs_cmd_t structure used for ZFS
ioctls is larger than 4kB.
Silence on: arch@
MFC after: 1 month
Revision Changes Path
1.18 +3 -2 src/sys/sys/ioccom.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004011621.o31GLkU5074268>