Gee that's funny, I don't remember anything in the PCI spec about having to have PROMs...;P
It's in the Open Firmware (IEEE 1275) bindings for PCI.
The reason is so that the firmware can initialize and use the card (ethernet, video, etc.).
Is it reasonable to expect a UltraSPARC to have to run x86 code to initialize a PCI card?
Because if it's not a FCode (OF's byte-compiled variety of Forth) driver, then that's the only other option.
This is bad for two reasons. First, I hate it when vendors screw with the PCI specs. It was adopted as a spec for a reason, not so vendors can then change it so it only works with their HW. Just ask linux-kernel how much they love broken PCI workarounds...
Sun has not "screwed with the PCI specs", FCode and PC BIOS drivers can co-exist in the same declaration ROM. PCI UltraSPARC systems can use PCI cards without FCode drivers, but such cards may be less useful (consider a video card for instance, waiting for the kernel to be loaded before any video is seen is undesireable).
Reason 2 is that "plug and play" (a Micro$soft term BTW) can be had for PCI without having those PROMs on board. The reason Sun uses those PROMs is to get licensing fees from hardware vendors to get that "Sun Compatible" moniker. Creative revenue generation no doubt, but it prevents PCI interoperability, which is a Bad Thing.
If "interoperability" is defined as "is either x86 or emulates it", then yes, it's prevented.
It's not Sun's fault that most vendors of PCI cards are x86-centric and don't see the value of FCode drivers on their cards.
It's also sad that only two major architectures use Open Firmware (SPARC and PowerPC).
Intel has even gone so far as to reimplement OF poorly in its "Extensible Firmware Interface" rather than simply defining IA64 and IA32 bindings for OF.
I'm not familiar with Sun's branding program, but it's not just "creative revenue generation".
drc@isc.org writes: >I find it unfortunate that ISC is put into the >position of being either standards conformant >xor "free" according to the Debian folks.
I think it's unfortunate that software patents have to put Debian or ISC into this position.
Sorry, but if your distro is using a glibc2 prior to that, it's based on a pre-release developmental C library.
That may be the impression presented by the glibc 2.0.x documentation, however, glibc developers recommended that distributions use glibc 2.0.x, and 2.0.x was on ftp.gnu.org (pre-releases are not allowed there).
Slashdot Mirror
It's in the Open Firmware (IEEE 1275) bindings for PCI.
The reason is so that the firmware can initialize and use the card (ethernet, video, etc.).
Is it reasonable to expect a UltraSPARC to have to run x86 code to initialize a PCI card?
Because if it's not a FCode (OF's byte-compiled variety of Forth) driver, then that's the only other option.
This is bad for two reasons. First, I hate it when vendors screw with the PCI specs. It was adopted as a spec for a reason, not so vendors can then change it so it only works with their HW. Just ask linux-kernel how much they love broken PCI workarounds...
Sun has not "screwed with the PCI specs", FCode and PC BIOS drivers can co-exist in the same declaration ROM. PCI UltraSPARC systems can use PCI cards without FCode drivers, but such cards may be less useful (consider a video card for instance, waiting for the kernel to be loaded before any video is seen is undesireable).
Reason 2 is that "plug and play" (a Micro$soft term BTW) can be had for PCI without having those PROMs on board. The reason Sun uses those PROMs is to get licensing fees from hardware vendors to get that "Sun Compatible" moniker. Creative revenue generation no doubt, but it prevents PCI interoperability, which is a Bad Thing.
If "interoperability" is defined as "is either x86 or emulates it", then yes, it's prevented.
It's not Sun's fault that most vendors of PCI cards are x86-centric and don't see the value of FCode drivers on their cards.
It's also sad that only two major architectures use Open Firmware (SPARC and PowerPC).
Intel has even gone so far as to reimplement OF poorly in its "Extensible Firmware Interface" rather than simply defining IA64 and IA32 bindings for OF.
I'm not familiar with Sun's branding program, but it's not just "creative revenue generation".
>I find it unfortunate that ISC is put into the
>position of being either standards conformant
>xor "free" according to the Debian folks.
I think it's unfortunate that software patents have to put Debian or ISC into this position.
-mcpu=k6 and -march=k6 are new in gcc 2.95
That may be the impression presented by the glibc 2.0.x documentation, however, glibc developers recommended that distributions use glibc 2.0.x, and 2.0.x was on ftp.gnu.org (pre-releases are not allowed there).
-- Joel, Debian package maintainer for glibc