>>Let me comment this in a more general way andnot only driver related:
>
>Some time ago, we had several attempts to discuss binary compatibility
>between different OpenSolaris based sitributions. If we take this for serious,
>Sun would have to honor "prior art" from older OpenSolaris distributions
>or installations from the community.
There might have been a discussion but there was never a conclusion other
than that Sun likes to define binary compatibility by way of a certain
"reference distribution". This would be the "Primus inter paris" of
distribution. (Or as George Orwell put it "some distributions are more
equal than others).
The reason for this definition is that it is cheap and possibly workable,
but on the other hand it's a definition which is too strict.
Since no one controls "all distributions" and distributions can be created
at random and incompatibly (like Nexenta is), a definition which includes
more than one distribution or software repository is not workable; and it
certainly wasn't defined that way. I would say there's still no
well-defined binary compatibility target other than Solaris 10/Solaris
Nevada. (Indiana, giving an incompatible user experience and scripting
experience is not such a release even if it aspires to be one)
>This of course also applies to "any solaris" + Blastwave.
Nope.
>Isn't Sun creating deliberate binary incompatibilities if a program with the
>name "foo" refers to different free software on recent Solaris express vs.
>Blastwave if the "first integration" was done at Blastwave much earlier than
>in Solaris Express?
These are several non-sequitors chained to make a logical argument, and the
flaws in the argument are as follows:
- If it's the same deadhorse, there is no incompatibility because
Sun renamed /usr/sfw/bin/deadhorse to /usr/bin/deadhorse whereas
Blastwave ships /opt/csw/bin/deadhorse. There are multiple
examples in Solaris of same command "foo" in different locations.
- This is not how compatibility is defined.
- Blastwave does its own thing and explicitly elects to erect
scaffolding of its own where the Solaris foundation could have
been used instead.
- We're talking about "Solaris, the Sun product"; any discussion
on how Sun's Solaris distribution is assembled from various
pieces of open and closed source is pretty much outside the scope
of OpenSolaris.
- Al is right, "first to integrate" is still the norm.
- "First toIntegrate: has never been defined in any other sense than
"shipping as part of an offical Sun Solaris distribution".
(emphasis on *shipping*, *official* and *Sun*)
Over time, we have seen a number of conflicts which have, AFAIK, all been
steamrollered in Sun's favor:
Sun's infiniband driver "ib" conflicts with a "ib" driver for some
expensive piece of equipment with a driver for Solaris which sets
you back $1000s. The Infiniband folks have not felt the need to
change this.
HAL's Solaris/64 2.5.1(?) was a Solaris distribution for SPARCv9; it
is NOT source or binary compatible with any of Sun's Solaris
SPARCv9 releases, even though it was first. (It uses ILP64)
The world is too big a place to allow any odd software producer to mandate
certain restrictions on future software releases. That's why the
narrower scope of "stuff actually shipping in Solaris" is used.
For drivers the picture is not pretty: both conflicts in naming (the ib
driver, new nVidia vs old nVidia) as well as conflicts in supported
devices (a differently named opensource driver vs a vendor (non)supplied
driver) cannot be resolved other than by installing just one of the
conflicting drivers.
Both the inability to bind a specific driver to a specific node and the
flat namespace which makes it impossible to have multiple "ib" or other
drivers require a considerable amount of rearchitecting. But it's not a
pressing problem as the conflicts are rare and effect few systems.
Conflicts for command names can be resolved as always: just use different
path names and call commands by their full pathnames.
Now stop flogging the dead horse.
Casper
Casper
