Keeping such code out of the consolidation doesn't seem fair; Linux has
The gate is a shared resource; once something
is putback, we all agree to maintain and support it as a first class
citizen for as long as it remains. We are absolutely not going to go
down the Linux path of incorporating garbage and letting it rot in the
gate forever.
Would it help this discussion to introduce the concept of multiple
gates? That is, because of various historical reasons, we have the ON
consolidation/gate that includes several kitchen sinks: Core OS,
Posix utilities, drivers, per-ISA and per-CPU support, etc. What if,
instead, we broke this up into several smaller, but related gates.
It would be a non-trivial task, but it would give us a model whereby
we could support the somewhat independent evolution of each and allow
us to add new instances of ISAs, CPUs and utilities when desired.
As an example, we could have
many Utility consolidation(s)
depends on
A single Generic OS/Net consolidation
which includes ddi/dki/hal/... interfaces
depends on
many Generic drivers (pseudo, nexus...)
depends on
many ISA consolidations (sparc, x64, ppc...) and
many ISA specific drivers
depends on
many CPU instances and
many CPU specific drivers
Each "many" in the list above could map to a set of projects under a
community that maintains the gates for those components. Or there
could be some other model.
By having multiple consolidations/gates, the various distro builders
could choose which ones to include and which to exclude. Sun, for
example, might choose to ignore all the PPC consolidations, the x86
CPU instances of the x64 ISA and the US-I CPU instances of the SPARC
ISA...
-John
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
