[driver-discuss] [osol-code] "community supported hardware"

[Garrett D'Amore]

Rich Reynolds wrote:
> I have read through the discussion, and this reeks of an opportunity 
> for a high volume code fork...
>
> all the detail is great, but i have a problem with the organizational 
> structure..
>
> I suspect this needs to be a project in device drivers...

I have other reasons for not wanting it to be in that community.

1) this potentially extends well beyond just "device drivers", into 
platform support and such
2) device-drivers is basically a defective community with almost no 
cohesion and *no* leadership  (look at the stale pages for it that 
haven't changed since 2005)
3) I think we want CC grants that might deserve representation outside 
of the normal interests of "device-drivers" -- there are platform 
support considerations as well, for example

That said, I hate the idea of governance getting in the way of things 
here.  Its been pointed out to me that if the governance issues here 
become too burdensome, maybe the simplest thing to do is post a 
repository somewhere (not on opensolaris.org) and let those who want to 
participate do so.

The organizational concerns here should not get in the way of providing 
a solution to the problem of making drivers and platform support 
available for those who want it.

    - Garrett

>
> rich
>
>
> 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
>>
>> _______________________________________________
>> opensolaris-code mailing list
>> opensolaris-code at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>