On Wed, Oct 28, 2009 at 12:17 PM, Peter Dennis - Sustaining Engineer <peter.den...@sun.com> wrote: > A simple +1 from me. > > 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
+1 Although I'm not sure this is going to be a valid anything today. I do have here an UltraSPARC5 who does do well via a classic serial console. I would however love to track down any of the VME bus based SPARC systems (or even an M68K) based systems that were popular some time ago. ----- Gregg C Levine gregg.drw...@gmail.com "This signature was once found posting rude messages in English in the Moscow subway." _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
