Garrett D'Amore writes:
> 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.
If you're passing "large" amounts of data with an ioctl, and you're
using those standard macros, that's true. It could have more of a
comment than just "parameters must be < 256 bytes."
> > 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.
I think there's also value in having the kernel know exactly how much
it should be copying, and not allow an application to 'trick' it into
copying a different amount by changing the lower bits of the ioctl
number. It opens some interesting possibilities for hacking.
That said, a lookup table needn't be complex, and can in fact be
directly addressed by (cmd & 0xff) -- the lower 8 bits have the 'y'
value.
> > 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.
As in the "_IOWN('X', 12, 32)" output? I'm surprised that the third
argument displayed matters to anyone. It's the second one that
usually defines the ioctl in use.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
