James Carlson wrote:
Garrett D'Amore writes:
In the OSS code, there are literally dozens of ioctls spread around.
Rather than creating custom copy-in/copy-out code for each command, I
have common a small bit of common code which looks at the encoded size
and direction and handles the copying. The savings is probably hundreds
of lines of code. It makes for a much smaller/simpler architecture.
(Admittedly it only works for OSS because the structures themselves do
not contain any pointers, so a single copyin/copyout is sufficient.) It
is especially important that I'm able to do this in the common framework
because of the complexities of M_COPYIN/M_COPYOUT handling in STREAMs code.
That's fine; you can define your own personal macros for these things.
Yes, I agree. I was hoping to be able to benefit everyone, but at this
point, the whole issue has become contentious enough that I think I'll
abandon the attempt to touch the common code.
Someone really needs to put a big honking comment in the header
indicating that nobody should be relying on structure sizes with these
macros. Frankly, any *new* use of the versions that take sizes should
be seriously discouraged -- folks expecting that the size will be
preserved will be seriously disappointed if they have not paid careful
attention to the rather limited mask.
Its not the first time that this problem has annoyed me either. In the
past (~a decade ago), I've personally made design decisions to avoid
large structures in ioctl arguments, if I was going to use these macros,
or avoided the macros altogether, because of the encoding limitations.
There's no real limit here. It's only the ioctl number that's at
issue; the actual copy in/out is done by the kernel module that
receives the ioctl, and it can copy *any* amount of data it wants.
There is value in passing the amount (and direction) of data to copy in
the code. It avoids having a lookup table, or explicit code, to do the
same thing.
I'm talking about code that is "common" to one kernel module, but might
handle dozens of ioctls.
As I said, I won't even bother with this if I can't do this in some
common fom. Special casing ioctls that should be able to be handled by
common code is just plain wrong, IMO.
It's how truss has worked since ... well ... forever. For the cases
where the ioctls matter enough to dump the buffers in some readable
format, add a handler.
If the ioctls are just some internal goop that's of interest to one or
a very limited number of projects, then don't bother.
There's certainly a judgement call to be made here, but I can't seem
to end up in the case where I want truss to dump out large buffers and
I'd prefer to count the bytes while looking at the structure in the
header file to figure out what's going on.
I'm not concerned about dumping buffers, I'm talking about the decode of
the command itself.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
