You are correct Mario.
A lot of the drivers for QNX4 did use the _CA_PCI… calls
to get info on the device. They were just simple wrappers for
the PCI BIOS calls themselves and could be called by any
root process at any time without any sort of protection mechanism.
However, a lot of QNX4 drivers still allowed you to specify
the hardcode interrupt and address values directly on the command
line. Additionally, and perhaps most importantly, the IDE and
filesystem drivers did NOT have to use the PCI calls and would
work just by bashing directly on the standard IDE port addresses.
The issue is, QNX4 would still work without a PCI BIOS.
You might have to hack some drivers here & there and setup
some pretty heavily customized startup scripts, but it was doable.
From what I’ve seen so far, QNX6/RTP is nigh on to impossible
to even get to boot up if you don’t have a PCI BIOS in the system.
Maybe its not an issue that we need to have a “pci-x86”, but instead
need the device drivers to be able to handle hard coded command
line options for all their addresses and interrupt values rather than
the “plug & pray” method that appears to be in vogue at the moment.
It is not the addition of better plug & play type management in QNX6
that I object to, it is the omission of most of the old “legacy” override
options that used to be present on many older drivers. This includes
both PCI and ISA devices. Just because a device is on the PCI bus,
does not mean that it will not be hardcoded to use specific I/O,
memory, and interrupt values. This is especially true on an embedded
platform – which is exactly where most people have historically
used QNX (that and high end medical grade systems).
For both high end and low end systems, the entire plug & play concept
needs to be discardable/disable-able. It is safest to have everything
assigned to fixed addresses and fixed interrupts that you KNOW will
work properly EVERY time and never cause conflicts. And since you
are 100% in control of the hardware design and do not allow anyone
to add devices without your control, there is NO need for any plug &
play type configuration. All it does is add the possibility for invalid
configurations and lower system reliability.
i.e…
Desktop: PnP = Good
Embedded: PnP = Bad!
Mike Burkey
“Mario Charest” <mcharest@nozinformatic.com> wrote in message
news:3af1b647.27085937@inn.qnx.com…
On Thu, 03 May 2001 13:33:50 -0500, Igor Kovalenko
Igor.Kovalenko@motorola.com> > wrote:
Mario Charest wrote:
“Michael D. Burkey” <> michael.burkey@nexwarecorp.com> > wrote in message
news:9cp87j$ghu$> 1@inn.qnx.com> …
The bigger issue in all of this is NOT the PCI server itself, but
the presence or absence of a physical PCI BIOS in the box.
Under QNX4, none of the device drivers were written to use
a PCI server, they just basically looked for the devices at a
set of hard coded physical addresses that were initialized to
those locations prior to the start of the QNX kernel (by the
BIOS or a hard coded startup routine).
??? What are the _CA_PCI… call for then?
Nothing prevented several apps from calling those simultaneously and
that apparently caused trouble.
Interesting.
However my point is that under QNX4 many drivers don’t go and look
at hard coded physical address, they use the _CA_PCI… call
which I always assume talk to the PCI BIOS.
Note, in early versions of NTO2 pci-bios
server used to be pci-bios.so (DLL) and that was changed later, I guess
due to same reasons.