Ian M. Zagorskih <ianzag@novosoft.ru> wrote:
thank you, rennie, this is really new and important information for me > 
- but actually i meant smth absolutely another. let assume for simplisity
that we have all needed priviledges, correctly linked executables and
so on. ideal case. and we have also some set of drivers that need to
access some installed hardware. note that all this drivers were done
by some different third party companies and anyway we have no
access to the source code and sometimes it’s even difficult to access
the authors to get some consiltations a’la “how damn it works ?!”.
and so, now we must to get working all this stuff together proper
way without any conflicts. again ideal case.
there’s a lot enough chances that some hardware/drivers use the
same io ports or mapped memory or interrupt requests or dma
channels or smth else [did i forget smth ?].
The problem, here, is that if the hardware uses conflicting
ioports, irqs, or memory address ranges then it doesn’t matter
whether or not the OS only allocates the “logical use” of that
resource to any one driver – the hardware configuration is
already broken and the OS can’t fix it. (Well, in the PCI
situation, it might be able to. QNX4 doesn’t do plug&play,
so the PCI-BIOS has to resolve these conflicts. And if you
are using ISA cards, these can’t generally be dynamically
reconfigured by the OS.)
So, you have to resolve hardware conflicts at the hardware
level – if using ISA cards, jumper them properly. If using
a mixture of ISA & PCI cards, you must properly inform your
PCI bios of the resources (irqs, memory ranges, io ports)
that you have assigned to ISA cards so that the PCI BIOS
doesn’t assign them to PCI cards. From the software point
of view, PCI irqs can actually be shared between more than
one driver and more than one io card – though the drivers
do have to be coded intelligently.
In none of these cases, though, would the OS “reserving” a
certain irq/io port/memory range help to resolve the fact
that two pieces of HARDWARE have been configured with
conflicting resources.
If you are working in a non-BIOS PCI configuration model,
then it does make some sense – but QNX4 does not have
code or servers that would help with this, you would have
to write the PCI configuration & allocation code yourself.
(And resolve conflicts, etc.) (QNX Neutrino does have such
code and servers for at least some PCI configurations. And,
those servers allow you to register for and reserve resources
for your card/driver.)
- how do you see the reasonable realization of one of mentioned
above drivers having no underlaying os support ? when inside your
programm as far as it was started with root priveledges you can
do actually anything ? and more that, quite often you still have
to do this “anything” accidentally named by some one “tips & tricks”.
when all controlling functions on your [driver author] actions is
your personal deal ? when you can input/output data from/in any
port regardless to if it’s actually used by another application,
read/write data to/from any physical memory region and so on ?
the primary question is:
Again – applications don’t own io ports – hardware does. If
you write to the io-port belonging to some other piece of hardware,
then your driver is broken.
“how can you give the guarantee that written by you driver will
work in any situation as far as if serviced hardware is propertly
installed and configured ?”
If the hardware is properly installed & configured, then there will
be no conflicts in hardware between the resources needed by one card
and by another. In this case, your (properly coded) driver will never
want to write to a resource (memory/io port) that is owned by another
driver/program. (Well, unless you are trying to have two drivers
handle the same piece of hardware. Doesn’t sound like a healthy
configuration to me.)
note, that in real life your application can easily interfere with some
another without any notifications from os side or whatever else
about the conflicts in resources usage.
If there is a conflict in resource usage, it MUST be resolved at the
hardware level. If the hardware doesn’t conflict, the drivers won’t.
even assuming that it is
written absolutelly correctly and has no one bug, you cannot be
sure for 100% that everything is going right way just due to the
luck of controlling information. for example from os side.
The “controlling information” must be from the hardware configuration
side.
-David
QNX Training Services
dagibbs@qnx.com