In late November of 2002, OpenBSD creator Theo de Raadt [interview] announced on the project's mailing lists that after over a year of attempting to obtain useful UltraSparc III documentation, they had still not made much headway. In the email he rallied the OpenBSD community to help out, asking them to contact the people within Sun responsible for providing such information. C/Net reported on this in their story titled, Open-source clan in spat with Sun. The UltraSparc III is Sun's third generation 64-bit RISC architecture based processor.

Sun boasts their UltraSparc III as an "open" architecture, yet seem to recognize that there is insufficient information freely available for the open source community to support it with operating systems. I have been told that the required documentation does exist, however, with a Sun part number of 805-0408-05-P. An early version of this manual was allegedly made available to Linux developers once a Confidential Disclosure Agreement was signed (Sun's version of a Non-Disclosure Agreement), however no such offer has been made to the OpenBSD team, an offer that if made is likely counter to the project's goals.

I attempted to discuss this issue with Danese Cooper who works in Sun's Open Source Programs Office, with as of yet limited results. My goal is to gain a clear understanding of Sun's official position on this situation, something that to date they seem unwilling to discuss with me. My continued attempts to get direct answers are described within...

---

One of the great bonuses of open source projects is the accessibility of the developers. When I read about the lack of UltraSparc III documentation, I sent Theo de Raadt an email to learn more about this situation. He quickly replied, explaining, "The interfaces we need are just plain not documented." He went on to add, "[The OpenBSD project has] more docs on the "closed" hppa architecture than we do on the "open" ultrasparc III architecture."

Many have been quick to point out that as Linux supports the UltraSparc III architecture, it should be a simple matter for the OpenBSD project to learn what they need looking at this existing code. When I suggested this to Theo, he explained, "There are certain things that are easy to distill from other source code. Some device drivers are easy", while in contrast, "Caches and mmu's are not like that. The code to handle them ends up all over the place." Find his full explanation below.

My next step was to contact David Miller, who coded UltraSparc III support for Linux, asking for his opinion and wishing to learn more about the non-discloser agreement he is rumored to have signed. He quickly replied, "no comment", also expressing some annoyance that this issue hasn't been dropped.

Reviewing the earlier thread on OpenBSD's "misc" mailing list, I began my attempt to gain an official answer from Sun, approaching Danese Cooper on December 10'th. To her I sent a list of five direct questions, describing what I had read and asking for clarification. A week later I sent a followup email, as I had received no reply.

Finally, on January 6'th, I did receive a reply from Danese, explaining her delay to illness and vacation, noting, "I think I'm about ready to talk to you about this". I replied the same day, excited to finally, apparently be making progress toward obtaining answers to my questions. As it turned out, I did not hear from Danese again for three weeks, however unfortunately still leaving all of my questions unanswered.

So begins my education into large corporations, and the speed with which they move. When first reading Theo's email back in November, I assumed the lack of documentation was nothing more than a misunderstanding, as this is Sun, a company who has frequently offered significant contributions to the open source community, and who has ironically accused Microsoft of similar "non-open transgressions". On their Linux page they go so far as to say, "Linux is consistent with Sun's computing vision of employing open standards and nonproprietary interfaces to develop products and services that address the needs of a variety of environments." One begins to wonder if the UltraSparc III does not fall within this vision.

Thus far, the replies I've received to my questions lack any attempt to provide answers. What I assumed would be a straight forward process continues to drag on. If anyone reading this article works for Sun and is in a position to offer more substantial information, please drop me an email. I will post a followup to this article once I've learned more.

In a more recent conversation with Theo, he explained to me that activism works. OpenBSD's track record in dealing with situations like this one is quite impressive, and he's confident that with time and community pressure, change will happen.

Theo's sometimes bluntly direct personality and efforts leave many with a negative impression, but it's difficult to deny that it has paid off for him. The OpenBSD project has continued to grow and evolve over the past eight years, living up to its slogan, "Free, Functional and Secure", and in all probability will one day support even the UltraSparc III.

---

From: Theo de Raadt
To: Jeremy Andrews
Date: Sat, 25 Jan 2003 12:36:21 -0700

There are certain things that are easy to distill from other source
code.  Some device drivers are easy.  You're whacking registers to
send a block, you whack registers to receive a block, you have some
setup code.  Device drivers work pretty much the same in all systems.
Jason can distill the information from a linux hppa audio driver (he's
never worked on hppa before) into an openbsd hppa audio driver in a
couple of days.  He's an expert.

Caches and mmu's are not like that.  The code to handle them ends up
all over the place.  The models of these things are widely varied:
standard, inverted, writeback, virtual, partially tagged, cache
aliases, write buffer pipelines, prefetch buffers and caches, delays,
etc.  And to add to that, some systems now come with 3 levels of
caches that have DIFFERENT semantics.  The vm system and the page
handling, as well as how dma interfaces with all of it -- that ends up
scattered throughout the kernel.  On an i386 (or vax or m68k) with a
physical cache and a mmu that has basically one tlb flush instruction,
and dma is so easy, after you get past the pte handling code, the
remaining cache/tlb/ugly glue code is perhaps 50 lines.

On a sparc64 or alpha or sparc, that nasty code is fully 50% of the
non-device driver part of the kernel.

Let me explain by showing you the sparc code.  It's the best example.

      81     442    3006 sys_machdep.c
      90     529    3580 iommureg.h
      91     605    3759 clockreg.h
     101     340    2472 db_trace.c
     103     564    3648 locore2.c
     147     646    4417 process_machdep.c
     167     749    4954 amd7930intr.s
     173     721    4925 auxreg.c
     225    1168    7266 in_cksum.c
     241     764    5868 db_interface.c
     242     865    6020 mem.c
     258     951    6528 openprom.c
     263    1391    9684 cache.h
     265    1082    7497 memreg.c
     288    1384    9654 cpuvar.h
     314    1244    8200 bsd_fdintr.s
     329    1331    9042 kgdb_machdep.c
     334    1379    9692 iommu.c
     381    1583   10759 intr.c
     445    1546   10553 emul.c
     470    1986   13059 conf.c
     542    1950   14012 vm_machdep.c
     611    1899   15195 svr4_machdep.c
     685    2603   18170 disksubr.c
     840    3150   21292 cache.c
    1014    4677   36707 db_disasm.c
    1162    4054   27721 machdep.c
    1185    4883   31326 trap.c
    1365    4674   31157 clock.c
    1371    4388   33466 cpu.c
    2216    7285   51181 autoconf.c
    6477   30195  171638 locore.s
    6771   23951  168266 pmap.c

Look at the size of that pmap module!  It deals with 3 mmu types, and
part of the code for the 4th mmu type (sun4/400) is in there, but not
yet functional.  The mmu types are: sun4, sun4c, and sun4m.  There are
variations in the sun4m land: TI vs Ross.

David Miller never got sun4c working on UltraLinux because he punted on
the virtual cache alias problem.  I think he could not believe someone
would design hardware so bizzare, but this is back in the days when
mmu TLB's were just VERY EXPENSIVE 12ns SRAM chips on the board.

And it was quite apparent from Torek and my code how the sun4c virtual
cache aliasing should be handled.  Yet he did not copy our code.  It
was too difficult.  I know he spent countless hours trying to figure
it out from our code.  Yet he did not get it working, and punted, and
got his US3 manual under NDA and moved on and worked on those machines
instead...

The same applies in sparc64 land.  Now, there's no way we can look at
what he did _with_ documentation, and figure out how it could apply to
us.  There's always people who suggest it is possible, but the pain is
so high, it's just not worth it.  Especially when the Linux kernel's
interface with hardware is detailed about as well as the Linux manual
pages.  Especially when Linux is famous for stuff like: writereg(0x4,
0xff01);

---

Theo de Raadt has expressed his views regarding activism on OpenBSD mailing lists in the past:

"Activism works.

"Just like I don't buy Nike shoes, and I buy gas from someone other than Shell when it is easier, activism is not some temporary thing. Activism does change the world, perhaps not as much as we want, but at least it moves it a bit in that direction. I don't care what the jaded people say; they are just making up cynical excuses.

"And anyways, activism can be a hell of a lot of fun.

"You can win what you ask for, but if you do not win -- you have still lost nothing.

Time? What's that? Time is only worth what you do with it."

---

From: Theo de Raadt
To: Jeremy Andrews
Date: Sat, 25 Jan 2003 12:49:05 -0700

Qlogic scsi support exists in Linux and *BSD because I forced them to
release their firmware to the community.  I had a discussion in the 2
weeks leading up to one of our releases, and we fully intended to ship
with the qlogic support REMOVED.  FreeBSD and NetBSD people were
mostly agreeable towards doing the same.  Then it got fixed.

Adaptec had a similar problem.  3com 3c990.  etc etc etc etc

There's perhaps 20 of these hardware documentation or firmware
licensing stories that I directly handled.

---

From: Jeremy Andrews <jeremy@kerneltrap.org>
To: danese.cooper@sun.com
Subject: Sun UltraSparc III Documentation
Date: Tue, 10 Dec 2002 20:18:01 -0500

Hello Danese,

  I maintain an active web site that discusses open source kernels, and
have been following a lengthy thread on one of the OpenBSD mailing lists. 
The OpenBSD founder, Theo de Raadt, explains that they are unable to
obtain sufficient documentation on the UltraSparc III, and thus they are
unable to support this "open" architecture with their operating system. 
I'm in the process of writing an article about this situation, and I'm
hoping you could help clarify a few points points for me.

  Are you the correct contact for this situation?  If not, please let me
know who is and I'll happily redirect the following questions.  I do wish
to quote you (or whomever may be the correct contact), is this okay?

1)  Does Sun consider the UltraSparc III an open architecture?  If so, can
you define what you mean by "open"?  What limitations does this still
impose upon thorough documentation?

2)  The OpenBSD team claims that the currently available documentation is
not sufficient to write a kernel.  As I understand it, Ahmad Zandi at Sun
has agreed that this is a true statement.  Why then has the OpenBSD team
been denied access to the necessary documentation required to support the
UltraSparc III architecture?

3)  Theo has told me that he believes the reason these documents have not
been made available is to hide some "nasty bugs".  Can you confirm or deny
this?

4)  Theo claims that certain Linux developers have been provided more
UltraSparc III documentation than is publicly available.  Can you confirm
or deny this?

5)  Does Sun take this issue seriously?  If so, what steps are being taken
to rectify the situation?
    
    
  Thank you very much for taking the time to read my email.  I would be
quite grateful if you could provide me complete answers to the above
questions, as I am interested in representing all parties objectively.

Thanks again,
 -Jeremy

--
 Jeremy Andrews    <mailto:jeremy@kerneltrap.org>
 PGP Key ID: 8F8B617A  http://www.kerneltrap.org/

---

From: Jeremy Andrews <jeremy@kerneltrap.org>
To: danese.cooper@sun.com
Subject: Sun UltraSparc III Documentation [2nd communication attempt]
Date: Tue, 17 Dec 2002 19:03:53 -0500

Hello Danese,

  I wrote you a week ago with a few questions regarding the UltraSparc III
architecture in an attempt to understand issues reported by the OpenBSD
team on their various development mailing lists.  I will be posting a
story on my kernel related news site (KernelTrap.org) regarding this
issue, but I would very much like to get Sun's official views on the
situation first.

  As stated in my original email, please let me know if you are the wrong
contact for these types of questions.  In that case, it would be greatly
appreciated if you could then point me toward the correct contact.  I
received your email address from Mr. Theo de Raadt of the OpenBSD project
who informed me that you were the contact that he has been speaking with.

  A response would be most appreciated.  If I do not hear from you within
the next two days, I will work my way up the list until I get a response
from someone.

  My earlier email is included below for your convenience.

Regards,
  -Jeremy Andrews

--
 Jeremy Andrews    <mailto:jeremy@kerneltrap.org>
 PGP Key ID: 8F8B617A  http://www.kerneltrap.org/