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...
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);
"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 <email@example.com> To: firstname.lastname@example.org 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:email@example.com> PGP Key ID: 8F8B617A http://www.kerneltrap.org/
From: Jeremy Andrews <firstname.lastname@example.org> To: email@example.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:firstname.lastname@example.org> PGP Key ID: 8F8B617A http://www.kerneltrap.org/