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.
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.
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.
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.
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...

Popular posts from this blog

SP (nanomsg) in Pure Go

An important milestone

GNU grep - A Cautionary Tale About GPLv3