+1. I would like the package for the "community supported hardware"
will be self contained. That is,
ON tree is not necessary to build the package.
Garrett D'Amore:
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
--
Best Regards,
Ming.
------------------------------------------
-Edward Shu
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
