Numerous other header files documenting private APIs are provided, while
numerous others are *not*. I think the attitude that a header file that
provides only internal APIs should probably not be installed by default.
Yes, it probably inconveniences a small set of users who use freeware
drivers that use GLDv3. But, quite frankly, those freeware drivers
should not be using GLDv3 if not integrated.
Did you know that the GLDv3 is *different* on S10 and S11? Which one
are you using? They are not binary compatible! Heck, they aren't even
*source* compatible!
GLDv3 is still a work in progress. If you want a stable API, use
GLDv2. If you want to experiment because you're brave, just grab the
source. I don't think as a distribution Sun's branded Solaris Express
releases should have to try to make the latter use case particularly easy.
-- Garrett
Mike Ford Ditto wrote:
> Carl Hensler <[EMAIL PROTECTED]> wrote:
>
>> Yes, but ...
>>
>> Is this kind of restriction on access to code consistent with open
>> source development? The Linux world copes with the fact that a lot of
>> code is a work in progress. Things evolve, rapidly at first and then
>> more slowly. Consumers and participants accept the fact that things change.
>>
>> I understand our traditional rules for Solaris, but are they appropriate
>> for OpenSolaris?
>>
>
> This isn't really restriction on access, it's just annoying
> inconvenience. In fact, I would turn your question around: Why is GLDv3
> being handled *differently* from traditional rules for Solaris? There
> isn't supposed to be any implication of interface commitment just from
> shipping a header file. Why does someone seem to have gone out of their
> way to make GLDv3 especially inaccessible, compared to other private
> implementation details?
>
> I think the GLDv3 obscurity is just stupid. It seems to indicate a
> belief that Solaris is used by only two kinds of people: ISVs who depend
> on stability and forward compatibility, and end-users who only use ISV
> products and don't write code or look at how the system works. I'm in
> neither category. I *use* the system itself. I have always preferred
> Unix over closed systems because I can, if I want to, write code that
> does what I need today, taking full advantage of any internal, unstable,
> or ill-conceived system functionality that I can find, knowing full well
> that my code will rot away (or just get rm'd) after I'm finished using
> it. I've written dozens, perhaps hundreds, of useful programs that
> became obsolete a few months later as soon as I upgraded to a new OS.
> Looking back, I don't consider any of that effort to have been wasted.
> In fact, I see it as lingering examples of why I've always chosen to use
> open "hackable" systems and been very productive in doing so.
>
> To put a practical spin on this particular issue, when I installed my
> new Solaris server at home a few months ago, I downloaded an open-source
> driver for my NIC. It had been written and tested on the current GLDv3.
> I tried to build it but it didn't compile because, you guessed it,
> sys/mac.h is not present. And I knew, more-or-less, what to do... find
> a snapshot of the ON gate from the build that I'm running, pull it down,
> install mac.h somewhere (/usr/include?) and perhaps repeat a few more
> times depending on what else might be missing. But I didn't know if
> this meant I'd have to set up and learn how to use Mercurial, and didn't
> know how long this would take, so it was easier to find a GLDv2 driver,
> which meant I can't use IP instances, which meant I can't decommission my
> old firewall when I bring up the new machine, which means I can't really
> switch over yet to the new server in the way I plan to deploy it, which
> means the whole project is much lower on my priorities list now, which
> means I haven't gotten around to working on it lately... so here I am
> typing this email on my old Red Hat system.
>
> mac.h being missing isn't a fundamental barrier to adoption, it's just
> one additional glitch along the way, and, I think, a sign of an
> unhealthy attitude by the developers.
>
> </grumble>
>
> Of course, like many, What I'd most prefer to see is GLDv3 completed and
> made a committed interface.
>
> -=] Mike [=-
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
_______________________________________________
networking-discuss mailing list
[email protected]
