Jürgen Keil wrote:
> Garrett D'Amore wrote:
>
>> Jürgen Keil wrote:
>>
>>> What about SIOCGLIFFLAGS ?
>>>
>>> # pkgrm SUNWvirtinst ...
>>> ...
>>> SIOCGLIFFLAGS: invalid argument
>>>
>> Crap. I thought I tested this in my test program. I missed lifreq for
>> reasons unbeknownst to me. I'm going to fix it.
>> Stay tuned.
>>
>
> Seems that the putbacks for 6711665 / 6711691 have been backed out
> last night...
>
Yes, I had a conversation with the gatekeepers yesterday, and we agreed
that the best approach was to back out the fix.
At the moment, I'll probably reintroduce the fix for 6711691, which is
not impacted by this problem.
The fix for 6711665 I'm not sure about. One approach is to provide a
compatibility macro (e.g. #define IOCCOMPATSZ(x) (sizeof (x) & 0xff))
and use it to define the known bad ioctls. The problem is that this
fixes the ioctls that are defined in ON, it doesn't help ioctls using
these macros and defined elsewhere. (Note that nobody should be using
these macros! They aren't part of any public API, and the header
explicitly states that only sizes up to 255 bytes can be encoded. I
didn't expect anyone to violate those comments, which is what caught me
off guard.)
Anyone that needs this functionality in 3rd party code should not
#include <sys/ioccom.h>, but should provide their own private versions.
Anyway, the options for dealing with this long term are:
1) Leave it the way it is, and anyone that wants correct encoding (e.g.
OSS) will have to define their own private versions. The disadvantage
here is that common tools like truss will not be able to decode the
ioctls. But nothing new breaks.
2) Rename the macros so nobody can use them outside of ON. This would
force busted code to be fixed. The old broken 0xff mask would have to
stay in place though, since the ioctl values are fixed. (IMO, the old
busted codes should be changed to use _IOCN(), since clearly there is no
relationship to the size of the structure and the actual ioctl code.
sys/sockio.h misuses most of these ioctl values rather badly.) This may
break compilation of old code, but it will break detectably.
3) Introduce new fixed versions, and address (using IOCN(), or some
other approach such as the IOCCOMPATSZ() wrapper) the legacy macros so
that the bad definitions in ON (sys/sockio.h in particular) can get
fixed. This could introduce incompatibility for 3rd party code using
the sys/ioccom.h header directly to define new ioctl codes.
4) Using a combination of solutions above, the macros are renamed with
new definitions (with the wider mask), and the old definitions are
removed, and the code in ON is fixed. This avoids undetected
incompatibility, allowing new code to use common macros, but also makes
it slightly harder when porting code from BSD. (Macro names would have
to be changed.) There would still be breakage, but it would be detected
at compile time.
I'm leaning towards #4. 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.
Thoughts?
-- Garrett
> Another consumer of SIOCGLIFFLAGS was the tcpdump binary
> from the companion CD, which now failed with:
>
> # /opt/sfw/sbin/tcpdump
> tcpdump: SIOCGLIFFLAGS: lo0: Invalid argument
>
>
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
