I think the best way forward here is for me to populate a sample
workspace with perhaps Tadpole support revived and maybe one or two
drivers. (Perhaps the audiocs4281 driver, which would be new, as well.)
- Garrett
Steven Stallion wrote:
Sebastien Roy wrote:
On Thu, 2009-10-29 at 06:54 -0700, Garrett D'Amore wrote:
Edward Shu wrote:
+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.
It would be nice, but we'll need the ON headers at least, I think.
Logistically speaking, to make this work at all, I would think that your
repository would need to be a child of a snapshot of the ON gate. This
very much seems to me to be a project (rather than a consolidation) that
perpetually synchronizes with ON by regularly pulling and merging from
some snapshot of the ON gate (just like any other ON-based project).
Copying a collection of header files from the ON gate seems like a poor
man's way of simply doing development in a snapshot of ON itself.
I agree; its possible to have a child project stand alongside ON that
does not copy *anything*. In fact, this is how the Emancipation
driver-gate works; to build driver-gate you simply need to issue bldenv
just as though you were working within ON proper. The Makefiles take
care of the rest.
Not copying ON bits also gives the project some autonomy - I can imagine
that updating the headers every 2 weeks for a new release would be a
pretty big PITA.
Steve
_______________________________________________
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
