> >>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.
Multiple gates are not feasible when the interfaces between them are not stable. The original project at hand is talking about support for a particular CPU. The interface between CPU-specific code and platform- specific code and the rest of the kernel is not stable, nor should it be, and therefore cannot be separated into multiple gates. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
