James Carlson wrote:
Garrett D'Amore writes:
Right now, they are less than useful to my needs, because I actually
*need* to encode sizes, and the sizes that I need to encode are > 255
bytes. Frankly, the current definitions are dangerous, because I
Why do you need to do this? Why is it something that has not bothered
anyone else in the past 20+ years?
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.
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.
But if the issue is to contentious, then I will abandon any effort to
clean this up, and just use my own private definitions, and resign
myself to the idea that truss and such tools will just be stuck when it
comes to decoding my ioctls.
That's not true. I pointed out earlier that you can add your own
decoder into truss, and do anything you like with ioctl arguments.
Just add a new case to show_ioctl(), and use Pread to grab the data
you want.
Yes, I could write custom handlers for each of the ioctls. I have
dozens of the them to deal with. And that's just in this one
subsystem. Its not a clean approach. The common code should be able to
handle it. The only thing busted is the stupid too-small mask from
ancient 4.x legacy.
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.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
