Increasing IOCPARM_MAX.

[Pawel Jakub Dawidek]

Hi.

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 not on the other?

I suggest increasing IOCPARM_MAX to 8kB and making it independed of
PAGE_SIZE and architecture it is compiled for. This will allow 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, I could really used this change.

The patch is here:

	http://people.freebsd.org/~pjd/patches/ioccom.h.patch

Are there any possible problems with such a change or should it be safe
to commit as is?

BTW. I see the comment saying IOCPARM_MAX should be multiple of page
size, but I can't see why.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20100322/3edd27d4/attachment.pgp