Peter Memishian wrote:
> > I'll probably have to run a fast track at ARC to approve removal of the
> > old macros, although it shouldn't be too controversial since the macros
> > in question technically aren't part of any public API.
>
> This isn't a legal case; please don't put pedantry before common sense.
> Either make the argument that the macros aren't being actively used such
> that they can be safely removed, or leave them be. Also, please make sure
> that all stable ioctls (such as SIOCGLIFFLAGS) retain their original
> values, even if those values aren't "correct".
>
They *shouldn't* be actively used -- they aren't part of any API. I
can't really tell, although I know at least one case where external code
has (mis)used them.
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
believe not everyone realizes that the values are truncated. On other
FOSS systems, the values are not truncated unless excessively large (8K
or larger in most cases -- in one case 4K).
Anyway, I agree that the stable ioctls need to retain their original
values -- that should be obvious to everyone, and why I asked my
original change be backed (or a fix I had be allowed in), as soon as I
discovered that the values were different.
The question is whether we want to have useful values for these macros,
or just leave the breakage as is. I'm of a mixed mind. There seems to
be a lot of fear that breaking these would be bad. At least by removing
the definitions we only create a compile-time breakage for use of an
undocumented API, which seems wholly acceptable to me. (And far better
than an undetected run-time breakage.)
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.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
