Randy Fishel wrote:
+1 (and long overdue)
I have trivial suggestions, such as the ability to build and package
a single component (this, and others could be discussed within the
community), but the bulk of the proposal seems sound to me.
This would largely be supported. I have a template repo that we used at
Tadpole that did this kind of thing (I created the Makefiles for it
there), and it also supported parallel builds of both SPARC and x86 in
the same workspace, without requiring a half dozen or more Makefiles to
be changed when you add a new driver. I want to make all that work
properly in this new consolidation as well.
It might become a model for the closed uts bits in the future, but
that's out of scope for now.
- Garrett
---- Randy
On Wed, 28 Oct 2009, Garrett D'Amore wrote:
Now that Sun has made official moves to de-support certain hardware (and to be
fair this is not new ... for example some people have wanted UltraSPARC 1
support for a while now, but now it will be expanded to all SPARC workstations
other than U25 and U45), it seems like it might be a good idea if we had a
"community supported hardware" group and perhaps a dedicated code base.
What I'm thinking of is:
1) a new consolidation
* call it CSHW (community supported hardware) for now (other names?)
* (structured somewhat like ON, but probably considerably simpler)
* containing platform support and drivers not in ON
* drivers might also include userland components (X11 modules?)
2) the consolidation would be built "in parallel" to ON
* compile against a checked out copy of the ON source base at the same
time.
* then build 150 of CSHW would also be built against build 150 of ON
* (and possibly other consolidations such as X?)
* binary distro would only be "correct" if it made up of matching
components
* don't duplicate what is in ON -- this isn't a "fork", its an extension of
ON.
* will probably use a much simpler Makefile system without ON's limitations
* I will offer to set up the initial repo for it.
3) Sun would have no official support for this new consolidation.
* no support in bugster for this stuff
* not part of any official Sun distro
* caveat emptor
4) The "C-Team" for it would be made up of people from the community
* might or might not be Sun employees (have some thoughts here)
* majority non-Sun kernel contributors
* would be Core contributors
* if you want to be on this list, let me know
* volunteer gatekeeper and backup gatekeeper
* use OpenSolaris public systems for doing builds
* builds should not be very resource intensive -- there isn't that much
that has to be compiled
5) Initial things I'd think of integrating into it:
* the Tadpole SPARCLE support I recently yanked from ON
* restored SDcard functionality for SPARC (by simply compiling the ON bits)
* drivers for audiocs4281, and perhaps other less popular audio hardware
* perhaps "alternative" drivers for LSI "mfi" and "ce" hardware from
community authors
* stp4020 driver (after removal from ON)
* bpp driver (after removal from ON)
* other legacy PCMCIA drivers (pcram/pcmem ?!?)
* platmod support for SPARC workstations as they are removed from ON
* support for Ultra-1 systems from Rainer
* perhaps a revived le driver ported from NetBSD?
* perhaps other "architecture ports" ?? This might be trickier than you
think!
6) Rules for integration would be far, far looser than ON:
* code has to compile
* you have to assert that you have tested it
* no long term support commitment required
* no webrti, instead just an e-mail based review/approval for now
* (what do other consolidations use for rti approval?)
* code review still required
* include documentation (man page) as part of integration
* no ARC approval required
* can import ON Consolidation Private interfaces
* no duplicates of stuff in ON or other consolidations without
justification
* sign-off by one of the Core Contributors
7) Obviously this would require a new Community Group inside OpenSolaris
* three core contributors needed (need to identify two more besides me)
* mailing lists and webpages on opensolaris.org
* code hosted in mercurial on hg.opensolaris.org
* possibly separate defects.os.o category? not sure.
I'm willing to start the process on this - including setting up an initial
consolidation -- if there is enough other community interest. I need at least
two other folks who are willing to act as CC's though. My first nominations
on this would be Juergen Keil, Rainer Orth, Steve Stallion, and Jason King.
Of course, I've not really verified any of this with them yet; I'm happy to
take other suggestions or volunteers.
Note that I'm also willing to volunteer as the initial gatekeeper on this,
performing builds, etc.
If I hear the necessary support from the community-at-large and receive
confirmation of willingness to volunteer from appropriate CC's, then I'll go
ahead and start the process.
- Garrett
_______________________________________________
driver-discuss mailing list
driver-disc...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
