Part of the "Macintosh experience" is, the customers take the smooth
integration between hardware and software as granted. This is as we
know NOT the case with the PC. One of the reasons is, the run-time
drivers cannot be embedded in the expansion card's ROM. An other very
frequent source of conflict is the lack of "naming". On PC, if there
are two PCI devices using the same chip, there is only one way to
differentiate: based on subsystem-vendor ID and subsystem device ID.
There is no standard how to "hard-wire" these values - on most PCI
devices these values will be restored to default after re-start.
I do not know, what is a bigger issue. The first is a major
inconvenience: either the third-parties do a good job of timing and
release the new products so, that the drivers appear on ever-actual
CD/DVD distribution of Mac OS - X (and we will have a quite large
/System/Library/Extensions folder) or provide a hack (see XPostfacto,
etc.) so the customers will be able to install "postfacto" the drivers
on the boot volume. Of course, the vendors of mass storage devices will
be hit the hardest.
The second issue never could be resolved, unless a major hack (=
copy-protection) will be put on the hardware (PCI card). Here is a
sample. The company 'A' has a SATA card based on ACME chipset. The
company 'B' has a similar card, also based on 'ACME'. The first company
is marketing the card under "Best SATA from A", the second company
under "Best SATA from B". Each company invested time & money to create
their products, they are competing but each driver has a different set
of features. "A" is proud on it's product, so is "B". Today, this is a
non-issue on the current Macs. Both "A" and "B" have at least a minimal
Open Firmware driver and as required, they have "name" properties,
like "best-SATA-A" or "best-SATA-B" and there is no conflict. So
naturally, each company's driver is "matching" own name. A PC-based
"Mac" would see only somewhat like "pci1234,5678" for both cards which
will be very likely the same if they did not took care to differentiate
also based on subsystem ID-s. Many ASIC-s do not have the capability to
preserve the subsystem settings over reboot, thus both "A" and "B"
companies and esp. their customers and support will have very tough
Please, I would like to ask more knowledgeable people to tell me (or
others who are as ignorant as I am on that area) - what is really going
on with EFI? I did try my best to get the answer on these two simple
questions, i.e. "naming" and "embedding" support from people involved
with EFI. After waiting a month I still have no answer, not a single
e-mail. I did my best and subscribed to everything involving EFI - it
seem to be VERY VERY quiet.
In the case if it turns out, EFI does not support anything resembling
either the "name" property in O.F. or run-time driver embedding,
choosing it for the future Intel-based Macintosh would be a grave
mistake. Also, given EFI is not an IEEE-backed initiative and to my
best knowledge Intel is battling with AMD quite hard, I think (sorry
for ignorance again) it is unlikely, AMD would ever back EFI. Therefore
how much chances does it have to become a standard or even a
Thanks in advance to anyone who can shed some light. And IF there is no
definitive answer yet... How realistic is the deadline (begin/middle of
2006?) for the first Intel-based Macs to ship if it is not clear yet,
what will be the bootstrap process, will we have device tree (according
the published document regarding the universal binaries it won't be the
case), etc.? When can we get more information?
I did ask Apple DTS a very simple question, which does not even involve
EFI/BIOS/Open Firmware dilemma: "how far is the Darwin used on the
$1000 developer kit different from the x86 Darwin in Open Source? We
have hardware (PCI-X cards, etc.) which are not optimal in that kit
because of lack of high-performance slots. So should we use a generic
x86 Darwin on a PROPER PC which would fit our needs to fine-tune our
drivers or rather go and "purchase" the kit"? So far, I got no
meaningful answer on my question.
Sorry, our customers are very scared, they ask us questions we cannot
answer. We get VERY disturbing calls every day since the announcement.
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden