In late November of 2002, OpenBSD creator Theo de Raadt 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 here.
Why not just read the diff’s for the linux port geee i mean how hard could it be to just backport what the linux weenies did back into your kernel ?? This is how most real coders do it
Most modern day exploits are crafted using this method
just read the diffs for the merges that went in the night before the so called non disclosed bug is patched
“why not just read the diff’s…”
Why not just read the article, where he talks about how that’s too difficult to do, and in some detail?
I guess, in theory, if OpenBSD use Linux code for a starting point, that portion needs to be GPLed.
The final sentence:
“Especially when the Linux kernel’sinterface with hardware is detailed about as well as the Linux manualpages. Especially when Linux is famous for stuff like: writereg(0x4,0xff01); “
SUN has always done the most for open source but they always did them for the wrong reasons and then they always anger the open source community.
SUN spent millions on StarOffice, don’t have a corporate strategy except it’s a good soundbite for the slashdot crowd. SUN spent billions on colbalt, don’t have a corporate strategy except it’s a good soundbite for the slashdot crowd. SUN has a tiny 0.2% of linux hardware market (compared to the combined 70% by IBM/HP/Dell.)
While there is a great deal of blame to place upon Sun on this matter, the OpenBSD team has raised holy hell about this matter, cited only biased sources, and has in my opinion harmed their already tarnished reputation with their incessant whining.
In this case, the article’s author has e-mailed one person at Sun twice, and received most responses. While this doesn’t look good for the individual the author e-mailed, does this speak negatively for Sun as a whole? We have nothing back from Sun, not even knowledge of extenuating circumstances which would’ve prevented this individual from responding to e-mail. Perhaps the author could’ve tried contacting at least one other person at Sun?
Regarding the specifics of this case in regards to the OpenBSD team and Sun, I’ve seen very little factual information regarding how much contact the OpenBSD team has had with Sun. From what I’ve seen, it’s been mostly e-mail and telephone conversations with people who aren’t remotely qualified to handle what OpenBSD is asking.
I would see greater validity in OpenBSD’s claims if they were making greater strides towards porting OpenBSD to UltraSPARC III platforms. FreeBSD has made great progress in this department, being the first free operating system to support SMP on sparc64 platforms, and unless I’m mistaken they’ve done it all without documentation from Sun. OpenBSD is seeking documentation for esoteric security features when their OS isn’t close to managing UltraSPARC III hardware effectively. They’ve stumbled within the corporate bureaucracy, and now they’re whining about it.
Theo de Raadt will never evoke any sympathy in me.
There is a “showstopper” reason and it’s quite simple: If they were to port Linux code to BSD, they would have to GPL a significant part of OpenBSD, which would go directly against OpenBSD policy to keep as much stuff as possible under the BSD license.
>Why not just read the diff’s for the linux port geee i mean how hard could it be ?
Well, what if that source is GPL ?
Secondly, Sun _deserves_ to get some ranting about this, they really should be more open.
There is a “showstopper” reason and it’s quite simple: If they were to port Linux code to BSD, they would have to GPL a significant part of OpenBSD.
No one is asking for a port of the Linux code. In fact, Linux doesn’t even implement many of the UltraSPARC III features which the OpenBSD professes its desire to use. People are suggesting that the Linux codebase be used as a reference for the UltraSPARC III processor, however as many have pointed out this isn’t exactly the easiest thing in the world.
> i mean how hard could it be to just backport what the
> linux weenies did back into your kernel ??
Don’t know, why don’t you try it yourself?
> This is how most real coders do it
Yes, and because of this attitude, the next generation of the src is *still* not documented in any meaningful way, and people *still* have to reverse engineer such stuff.
“Gee, real humans lived in caves for a thousands years. Why are you asking for huts?”
I’m interested in knowing how good shape the FreeBSD sparc64 port currently is?
As far as I understand, FreeBSD/sparc64 is currently nowhere near as stable as NetBSD/sparc64 or OpenBSD/sparc64.
I’m also interested to know how machine independent the FreeBSD device drivers are: can you use any/most PCI device drivers support by i386 on sparc64 with FreeBSD.
Also, how much SBus device drivers there exists? NetBSD and OpenBSD have had sparc port for a long time, and they already had plenty of support for SBus devices prior to sparc64.
About reverse engineering from Linux, as far as I understand, there are a couple of points:
– Linux and OpenBSD VM, processes, et al critical things are implemented very differently.
– Linux sparc64 code is not too well documented.
– It’s no good reverse engineering undocumented code, which implements different things, and same things in different ways.
OpenBSD doesn’t scale well enough to support the large US3 machines (do they already support SMP)? So for them the UltraSparcs are just expensive door-stoppers that are so much slower than x86 systems that you can hardly buy comparable x86 systems anymore. They have a single advantage, 64-bit memory, but I doubt that the type of applications that typically run on OpenBSD needs it. So why bother when Sun refuses to release the specs for their obsolete processors?
Note this part:
> 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.
Now what is this? “No comment”? I mean, hell, if Sun doesn’t get their thing together to figure out whether or not they want to release that documentation and who’s responsible and everything, fair and well. But, “no commet”? What kind of reply is that? Politics?
🙁
> My next step was to contact David Miller, who coded UltraSparc III support for Linux, asking for his opinion
Now what is this? “No comment”? I mean, hell, if Sun doesn’t get their thing together to figure out whether or not they want to release that documentation and who’s responsible and everything, fair and well. But, “no commet”? What kind of reply is that? Politics?
David Miller is a RedHat employee, not a Sun employee. If anything, RedHat probably sees the OpenBSD project as competition.
OpenBSD doesn’t scale well enough to support the large US3 machines (do they already support SMP)?
OpenBSD does NOT support SMP (at least in production code, although there are people working on it)
The project had no problem getting the SA of the University of Alberta, where OpenBSD hosts its primary FTP site, to say he wanted to run OpenBSD on Sun Fire v880s, systems which come with a minimum of 2 processors… processors which each cost more than a complete x86 server alone.
So for them the UltraSparcs are just expensive door-stoppers that are so much slower than x86 systems that you can hardly buy comparable x86 systems anymore.
Well, that’s not really the case. For CPU bound applications (in our case a mesoscale atmospheric modelling program) we’ve found a Blade 2000 w two 900MHz UltraSPARC-III processors to be computationally equivalent to over 8 1GHz Pentium III processors. I can go into the details, but obviously Sun is keeping up in terms of performance alone. They are only failing in terms of price/performance.
They have a single advantage, 64-bit memory, but I doubt that the type of applications that typically run on OpenBSD needs it. So why bother when Sun refuses to release the specs for their obsolete processors?
Sun also makes highly reliable equipment, the likes of which hasn’t been seen in x86 servers. I can understand the decision to use Sun hardware from this perspective (perhaps in the case of the University of Alberta’s SA even) A Sun would also be suited to the highly I/O bound task of functioning as a router with a stateful packet filter, albeit a markedly expensive solution.
However, being in the position that they’re in, I wouldn’t take the OpenBSD team seriously if I were Sun. They talk about wanting to use advanced security features of the processor, yet they have no hardware compatibility with components located within typical UltraSPARC-III systems (how about that FCAL controller in the v880?) OpenBSD is getting a few years ahead of themselves by requesting this documentation, provided they’re truly serious about an UltraSPARC III port and this isn’t just Theo bitching because he isn’t getting his way.
I don’t say the OpenBSD guys couldn’t use some documentation from Sun, but keep in mind that if they really wanted they could just get the specs from http://www.sparc.com/resource.htm because SPARC, unlike the x86 and the Itanium1/2 is an open platform. It’s open in the same spirit as the Unix Group and POSIX: it defines clear interfaces and presents clear implementation documents. That kind of openness is much, much more useful than just open source, when the source is, as someone pointed out before, “writereg(0x4,0xff01)”. Sure it’s sweet to get such documentation from Sun, for the USIII implementation of the SPARC architecture. The Linux folks got it, by signing an NDA, so it’s not IMPOSSIBLE to get it from Sun.
Talking about snobbery, I have been trying to get in touch with a RedHat representative (PR) since last week, and all I could do is leave a message with my number asking to be called back (as their voicemail messages suggested), and yer nobody called me back, yet. And I am doing it so RedHat can do fucking money off of it, not for some unprofitable opensource project.
Oh, and while I’m offtopic; please noone ever tell me that you can “just download the RedHat .iso image and burn it, if you want ot try it out”, well, try to do that with Advanced Server: the only way you can try it out is if you spit out $800.
Anyway, nice job slamming a company that has provided the most standards-compliant Unix, running on an open platform (SPARC) powered by an open BIOS – OpenBoot – a completely open paltform, both specs, sources and hardware), and which has provided to the opensource community the only viable office suite.
I’m frankly amazed at how many of the posts here show a real lack of understanding of the situation… or an obvious lack of actually even having *read the article*.
Here is the situation. The USIII is the latest in the sparc64 series of sun architectures. Yes, OpenBSD *does* support the others, however, this one is relatively new and completely underdocumented.
Yes, linux supports it. Anybody who’s EVER tried to reverse engineer anything in a kernel will tell you, that if you can get documentation instead, you are saving yourself one heck of a headache. Read the article for Theo’s explanation of why. How did the linux developer in question get the documentation? He signed an NDA – this is completely against OpenBSD’s stated goals, and most definitely NOT a sign of open-ness.
Danese Cooper is the sun representative for open source initiatives. Who else should they be contacting?? Sun is a rather large company, the author, and the OpenBSD developers, have repeatedly stated that if they should be contacting someone else, they are open to suggestions.
My take on Sun is this – their ‘openness’ is a PR reaction to the free software movement. It makes them look good to the community, in opposition to obvious evils like Microsoft. Yes, they have done some good things for the community. They also have shown they can be just as closed as anybody else, when it suits their goals.
to: Acheron
Thank you. At least one person here understands the situation.
Sun doesn’t give a flying F**K about OpenBSD because they don’t see any ROI in “supporting” that OS.
In other words, they don’t have a business model to capitilize on services revenue from OpenBSD.
McNealy is the quintessential politician… He accuses Gates of abusing the very power he wants for himself.
Also, companies are becoming so paranoid about their IP these days (Intergraph’s new business model provides some justification for the paranoia) that I bet Sun has a whole team of lawyers going over OpenBSD’s request and Ms. Danese Cooper has the unenviable job of stalling until the IP lawyers are able to consider the request from every possible angle.
Cheers