[oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle

[Ray Arachelian]

On 02/19/2014 10:34 PM, seth Nimbosa wrote:
> The reason we need a minimum of criteria for collaboration is
> precisely because the different distributions have different focus,
> approach, and use case scenarios in mind, but a set of core features
> that will make it to a unified kernel will be for everyone's benefit. 
> Additional layers will be built upon this basic core and the
> abstraction of these feature-sets and their encapsulation from the
> layers below and above it will ensure that there is more or less a
> predictable and uniform way each of these layers interact together and
> how they behave on top of the core.  I mean each distro-specific
> feature-set will be spun out and encapsulated into separate layers of
> development on top of the kernel (and these layers will be slightly or
> wildly different in each distribution) but the core will remain mainly
> intact but dynamically developed jointly by the different distros in
> an upstream manner.

Indeed.  That was the whole point of Illumos.org - it wasn't meant to be
an end-user distro, but rather the canonical source repository for what
once was opensolaris, to be used by the various end-user and commercial
distros, until such time as (either hell froze over or) Oracle released
the sources for Solaris 11, and it would accept upstream changes from
the various distros where appropriate.  Sadly it looks like the former
is more likely. 

So ideally, illumos.org is where kernel updates should be sent to.  From
the looks of it, ZFS is still being updated, as is d-trace, and various
other parts, so there is activity, but it's nowhere near the scale of
linux, or even the BSDs. 

It might be helpful to have some sort of ABI that allows opensolaris to
steal linux device drivers, or FreeBSD device drivers, either by
recompiling, or by providing a binary interface, but I've no idea how
difficult that would be.  Such an interface would allow quick porting of
missing device drivers, at a cost of poor efficiency due to the extra
layers, but at least it would provide some support for hardware that
isn't supported yet.  Timing sensitive device drivers wouldn't work very
well with such a scheme.  (And of course there's tons of license
compatibility issues there to ameliorate.)