Date: Tue, 23 Mar 2010 00:58:31 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: freebsd-arch@FreeBSD.org Subject: Increasing IOCPARM_MAX. Message-ID: <20100322235831.GC1767@garage.freebsd.pl>
next in thread | raw e-mail | index | archive | help
--DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuoBCYACgkQForvXbEpPzQEJwCg0MsFUQKlLqcyT61KUlDOf2PN pRkAoJiPEmyjURU3Uto2xlJLIQ2Q3M1U =wKYo -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100322235831.GC1767>