[OpenIndiana-discuss] e2fsprogs header file bug

[James Carlson]

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         <carlsonj at workingcode.com>