On Wed, 27 Sep 2006, John Baldwin wrote:
On Wednesday 27 September 2006 17:29, Ruslan Ermilov wrote:
On Wed, Sep 27, 2006 at 05:10:51PM -0400, John Baldwin wrote:
I still think doing this (via IOCPARM_IVAL()) is best and is probably a
much
smaller diff.
You don't consider that many ioctls are initiated inside the kernel,
and this kernel code already uses (and passes) pointers to "int".
While we could fix all of our kernel (and my first patch did exactly
this), it's 1) very inconvenient, and 2) we cannot fix third-party
kernel code this way.
Could you avoid IOWINT by just assuming that any _IO() ioctl is getting an int
as the arg? If an ioctl doesn't use the arg, then you don't lose anything..
No -- see ru@'s reply.
do we have any ioctl's that use the arg directly but not as an int? The
ioctl(2) manpage implies that 'data' is either a pointer or an int. If you
go this route, you avoid changing all the ioctl values, basically just assume
that IOC_VOID means the argument is an int.
The point of changing all the "void int" ioctls that actually pass an
int to use _IOWINT() was to get away from the horrible (kernel) API
and (user and kernel) ABI for them. The API is so horrible that there
were no instances of correct use of it. The complications for using
it are now mostly handled in IOCPARM_IVAL(), but we wanted to inhibit
future uses of "void int" so so changed the ABI so that new (user)
binaries use _IOWINT(). The ABI is still horrible because there aren't
enough bits to encode the types in a nice way.
Bruce
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
