Andrey N. Oktyabrski wrote:
> On 03.11.11 16:22, James Carlson wrote:
>> Andrey N. Oktyabrski wrote:
>>> More about e2fsprogs. Now from the pkgsrc. There is a same bug as here:
>>> http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=45499
>>>
>>> Is it correct to expect ifr_hwaddr member in ifreq structure if
>>> SIOCGIFHWADDR defined?
>>
>> It might be correct on some platforms. It wouldn't be correct on
>> OpenIndiana, because it doesn't exist on that one. In other words, the
>> application needs to be ported.
>>
>> I believe that ioctl only works on PF_PACKET sockets, and requires the
>> use of sockaddr_ll. See:
>>
>> http://arc.opensolaris.org/caselog/PSARC/2009/232/pfp-psarc.txt
>
> What solution would be correct?
> 1. Check it in the "configure" stage:
> if ${OPSYS} == "SunOS" then #undef SIOCGIFHWADDR in config.h
>
> In this case the software developers must do it in the "configure" script.
>
> 2. Remove the SIOCGIFHWADDR definition from Illumos/OI headers while it
> don't work.
>
> In this case Illumos/OI developers must correct header files.
I'd say #1. The reason I say that is that (a) the OI header does in
fact work, if you know how to use it, and that other software's failure
to understand how to use it really isn't OI's problem, (b) definition of
that macro does not in fact imply anything about the system, (c) there's
no fundamental system design requirement saying that #defines must be
omitted until the underlying implementation is "perfect" with respect to
some thoroughly arbitrary external reference, and (d) there's really no
standard saying precisely what that #define must do, so there's no
violation of type or conformance.
I do agree that partially implemented "Linux compatibility" things are a
bit of a hazard in general, and that this one in particular is a bit
sad. Taking that failure up with the developer of the feature (not me,
but he's not hard to find) might be interesting.
However, like the last problem with this same unported software posted
on this same list, this new problem exposes a number of fairly clear issues:
1. Non-trivial software needs to be ported in order to run on
different systems. All of us who build software that runs on
multiple systems really do wish it were otherwise, that somehow
standards bodies and market pressure would magically make every
system compatible with another, but we know that in the real
world, that just doesn't work. Porting is work.
As a corollary, software that hasn't been ported, like features
that are never tested, does not work. Period. It doesn't work.
2. Automatic configuration systems (such as, but certainly not
limited to, GNU autoconf) are not magic. Sometimes, in the hands
of skilled and wise developers, they help the process of designing
and then _TESTING_ software that is widely portable. But they're
not pixie dust that can be sprinkled on top in the hope that
somehow a slew of build-time tests combined with a rat's nest of
#ifdefs will make it all work out.
Perhaps more significantly: no automated test can (today at least)
determine what has been documented to work on any given system.
All that it can test is the contents of include files, symbols in
libraries, OS name and version, files/directories, installed
software packages, and, if it tries hard, kernel interfaces. None
of that substitutes in any automated way for an actual developer
reading the flippin' man pages.
3. Not all systems are Linux. Nor are they BSD. Nor are they
Windows. Nor are they Solaris. And so on. Assuming that there's
one special golden reference standard out there that "everyone"
must support is pure folly.
If everything were the same, well, there'd only be one OS in the
world, and I know I'd really be sad if we all had to write code
on Win7.
4. e2fsprogs is not greater in stature than OI. That is to say,
there's no reason I can see that OI should have to change in order
to pave a road for that one software project. Sure, if there are
objective bugs or flaws in OI, and if someone has the time and
ability to repair those things, then that's great, whether it does
or does not help e2fsprogs. But assuming that each
incompatibility between the two is in fact a problem is _either_
is, I think, deeply wrong.
One doesn't go visiting a foreign land and just "assume" the
residents there must speak the one's own language and, if they
don't, then they must be defective. That's not how it works.
Note that this goes both ways. I wouldn't expect software written
explicitly for OI to run well at all on the systems used by the
e2fsprogs developers. If someone wanted it to run there, then that
person would have to put in the work required to port the software over.
And calling their systems "broken" because they don't run native
Solaris software is not too productive.
But good luck with the quixotic homogenization quest implied by your
second choice. Maybe you can defeat the windmills.
> P.S. I can't understand, why e2fsprogs want any network-related
> headers... Of course, this question is for e2fsprogs developers.
That sounds like a pretty good question to me. Groveling around network
hardware addresses seems a bit far afield of file system utilities.
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
