proposal to change policy of SPARC deliverables

Historically, subsystems (drivers, etc.) were supposed to deliver on both SPARC and x86 platforms (and now amd64 as well) unless a really good argument was supplied. While I've long been a supporter of this philosophy, I think a time is coming to consider making a specific policy exception.

The problem I'm running into is with legacy PCI devices. Some of these legacy PCI devices can work SPARC. But devices that don't support 66 MHz frequently (but not always) have problems on SPARC workstations. The biggest problem is that many SPARC workstations have 32-bit 33 MHz slots that don't supply 3.3V. This affects quite a number of cards that require 3.3V power to operate. Some devices will operate with only 5V, but only marginally. I've seen a number of failures that I think can be traced to this problem, and now I don't recommend using PCI devices not specifically qualified for these platforms with SPARC systems. (Sun makes that same recommendation, btw.)

Furthermore, identifying suitable SPARC hardware can be a challenge. SPARC systems these days are slower than their x86 counterparts, yet for the most part remain more expensive, and there are few inexpensive options available for open source developers. And, SPARC desktop systems are effectively off the market -- Sun doesn't have any current SPARC desktop models for sale, and that's not likely to change anytime soon.

So what I'd like to propose is a policy change that recommends authors working on drivers for legacy PCI cards be given a blanket waiver for SPARC delivery. (Examples are recent NIC drivers such as "vr", "sfe", and "bfe", and audio hardware such as "audiopci", "audiocmi", and perhaps in the future drivers for Creative Audigy cards.)

I still believe that developers working with modern PCIe devices should deliver both SPARC and x86 binaries though. PCIe is available on last generation SPARC desktop (Ultra 25/45) hardware as well as current generation server products.

Comments

Milan Jurik said…
On opposite side, when we will give them blank waiver, many drivers will not be written for "big endian" world at all (so smaller code quality can be the result). And there is still large SPARC/Solaris userbase.

People who wrotes driver for some HW should know HW specification, so they should provide reasons why it cannot be supported on SPARC or it is not safe, in similar way how you did in your last PSARC case.

Look at our legacy drivers, you will find many cases where we were "highlighting" only one of these platforms, the other was "starving". It resulted in many forks, code duplicatications etc.
June 9, 2009 at 12:35 PM
Unknown said…
I'm only talking about legacy PCI devices. All newer drivers are for PCIe, and generally those should be supported on both SPARC and x86.

The problem is that properly supporting PCI (especially 32/33) on SPARC is quite difficult, and only getting more so as we move on. (E.g. framebuffers that won't be supported much longer, ultimately the end of SXCE will mean the end of SPARC workstation support, etc.) PCI 32/33 cards can work in SPARC, but they must pure 5V cards. 3.3V cards (or cards that need a 3.3V supply in addition to 5V) just don't work.
June 9, 2009 at 1:35 PM
Milan Jurik said…
Even with death of SXCE, Ultra45 will be usable system (with several graphic cards) in OpenSolaris. And I see 2 PCI-X slots there. So the most of "modern" PCI card should work there.
June 10, 2009 at 4:53 AM
Unknown said…
Yes, but how many community members have access to Ultra 45 and Ultra 25? Not many people even within Sun have such access.

The PCI-X slots work for 66 MHz cards, so I'd be OK with a requirement for 66 MHz cards going forward, but I think it should be waived for 33 MHz devices.
June 10, 2009 at 8:03 AM
Milan Jurik said…
Yes, not many people have UltraX5, but does it mean we, proud owners of them, are unimportant? :-)

Also, from PCI-X specification, even 32-bit 33MHz 3.3V cards should operate without problems.

I have nothing against waivers if they make sense (and they have usually in these cases). But in all cases short note "This is legacy PCI HW, so we do not target SPARC" should not be enough, at least minimal investigation/evaluation should be included.

Yes, Ultra60/80 has one 3.3V and three 5V slots, which is not very nice combination, leading to many troubles.

And as usually, if you have no access to such hardware for testing, you can ask around. If nobody has it, then it could be part of "why do not have the support SPARC" - lack of business reason :-(

And btw. in case of Audigy - Ultra45 is expensive but has very bad internal audiochip - Audigy could be nice option for somebody there...
June 10, 2009 at 4:00 PM
Post a Comment

Popular posts from this blog

An important milestone

Yesterday, with very little fanfare, illumos passed an important milestone. This milestone was the integration of  195 Need replacement for nfs/lockd+klm This is work that I originally tasked Gordon Ross and Dan Kruchinin to work while we were colleagues at  Nexenta .  Gordon started the work, picking up bits from FreeBSD as a starting point and gluing it to the illumos entry points.  Dan continued with it, and fleshed out a lot of the skeleton that Gordon had started.  It was subsequently picked up by the engineers at Delphix , and -- after some important bug fixing work was completed -- was integrated into their product quite some time ago -- reportedly its been stable since December in their product. The reason this is such an important milestone, is two fold: First, this represents a substantial collaborative effort, involving contributions from parties across several organizational boundaries.  The level of collaboration achieved here is a w...
Read more

GNU grep - A Cautionary Tale About GPLv3

My company, DEY Storage Systems , is in the process of creating a new product around the illumos operating system.  As you might imagine, this product includes a variety of open and proprietary source code.  The product itself is not delivered as a separate executable, but as a complete product.  We don't permit our customers to crack it open, both from the sense of protecting our IP, but also to protect our support and release engineering organizations -- our software releases consist only of a single file and we don't supply tools or source for other parties to modify that file. One of the pieces that we wanted to integrate into the tree is an excellent little piece of software called Zookeeper , produced by the Apache organization.  Like illumos, Zookeeper has a nice non-viral copyleft license, which makes it nice for integration into our product. However, I discovered that as part of our integration, one of my engineers had decided to integrate GNU grep. ...
Read more

The Hand May Be Forced

Well, as you may have read , Oracle has decided that at some point very soon, we're going to lose normal regular access to the source code for OS/Net. (I.e. the Solaris kernel and supporting programs.) While I would have vastly preferred for Illumos to have a cooperative and collaborative relationship with Oracle , it appears that Oracle doesn't value this. In fact, the exact words were from the management at Oracle were as follows: Solaris is not something we outsource to others, it is not the assembly of someone else’s technology, and it is not a sustaining-only product. While I understand the need to own the technology, there are few things that could be stated that show a stronger NIH attitude than this. Its unlikely that there will ever be a way for Oracle and the greater community to have a collaborative relationship. This is a dark day for OpenSolaris -- its effectively dead now. (Its parent, Solaris, lives on however.) How unfortunate. For Oracle that is. Because...
Read more