|
About two months ago my boss Simon got tasked by Jonathan Schwartz
to work out a process to respond to and, where ever possible, deliver
on requested chipset documentation. The key ingredients of the
process, as set forth by Jonathan, were to be openness and
transparency.
Who wants old docs anyway?
The
value in old chipset documentation is that it allows developers, such
as those in the *BSD communities, to write drivers that enable their
OS's to run on older (sometimes very much older) Sun gear.
Appropriately, Simon described the start of this effort in a blog entry
entitled "Hardware Archeology."
About two months ago my boss Simon got tasked by Jonathan Schwartz
to work out a process to respond to and, where ever possible, deliver
on requested chipset documentation. The key ingredients of the
process, as set forth by Jonathan, were to be openness and
transparency.
Who wants old docs anyway?
The
value in old chipset documentation is that it allows developers, such
as those in the *BSD communities, to write drivers that enable their
OS's to run on older (sometimes very much older) Sun gear.
Appropriately, Simon described the start of this effort in a blog entry
entitled "Hardware Archeology."
Unlike
other makers of chips who create their products for external use, for
most of Sun's history our chips and their docs have been produced for
use in our own products and not intended for external audiences (this
however has recently changed with the launch of Sun Microelectronics).
In order then to make these often "ancient" documents public they need
to be scrubbed by both engineering and legal to make sure there is no
third party trade secrets and that they are "public-ready."
To
drive this effort a cross-functional team was put together with
engineering, legal and members of the FOSS group. We started by
tackling seven ASICs that the OpenBSD community had previously
identified as their top priorities.
A wiki is born
Two
months later, thanks to the hard work of the Microelectronic
engineering teams who took this on as their "night-jobs," the
documentation for four of these (Psycho, Fire, Cheerio and Tomatillo)
have been made public
and the docs for the other three (Gem, Cassini, Schizo) are well on
their way. During this process I worked closely with David Gwynne of
the OpenBSD community to determine priorities and to determine the next batch of chips that OpenBSD is interested in.
But
the idea here is not simply to have one-on-one conversations with
select individuals but to open the process up so that anyone can make requests
for documentation and then track the progress of the request. The
vehicle we are using for this is the FOSS Open Hardware Documentation page which is part of the new wikis.sun.com site that launched at the beginning of this month and was created with the idea of enabling exactly this type of open communication.
Since
the Wiki was launched on Friday, a column has already been added for
implementations and David Gwynne has not only signed up for access to
the wiki but has posted OpenBSD implementations for three of the four
chips we've recently made docs available for!
So please join in. We cant promise that we'll be able to provide all documentation but we'll try our best and if we cant we'll explain why.
Pau for now...
Read the original article: . |
