Article:Talking to hardware under QNX Neutrino

[Warren Peece]

"Armin Steinhoff" <A-Steinhoff@web_.de> wrote in message
news:3A22CE43.79ED84B8@web_.de...

| My last 2 cencts:
|
| Using the same LIBRARY STANDARD ( for instance the
| POSIX standard, LINUX 'lib standard' or QNX4 'lib
| standard' ) for drivers doesn't mean that the
| drivers must share the same driver model ... e.g.
| LINUX drivers and NTO drivers are completely
| different but they are using the same standard for
| POSIX threads.
|
| We have the same situation if we take the LINUX or
| QNX4 PCI library definitions as a standard. IMHO
| ..we are just winners when we follow IT standards
| ...
|
| Armin

My last two cents (hey, stop clapping!):

Generally speaking, I agree with the concept that following a standard can be
but is not always a good thing. In this particular example, I believe that the
implementation of the QNX6 driver structure deviates sufficiently from the QNX4
as well as Linux implementations so as to warrant its own unique approach.
After all is said and done, in a couple of years we'll be thinking of it as the
QNX6 standard anyway.

Ladies and Gentlemen, thank you all for joining us today. Be sure to pick up
your free gift sets by the door on your way out, and remember to tip your
waiters and waitresses as they've all done a fine job for us this evening.
Thank you, and good night.

-Warren

[Armin Steinhoff]

Eric Berdahl wrote:

In article <3A228C34.48287B8F@web_.de>, Armin Steinhoff
A-Steinhoff@web_.de> wrote:

Chris McKillop wrote:
Armin - Linux Developers != Linux Kernel Developers. This is refeering
to the userland processes that run on Linux - things like KDE and Gnome
and GTK and all the text/console based applications. It is talking
about
the fact that one does not need to learn QNX's internal IPC mechanisms
and internal API to write software for QNX if you are used to writing
software
for Linux/UNIX.

Chris ... see the initial posting of Eric Behrdal.
I think he is describing a typical situation. His
question about the documentation of io_funcmmap()
is un-anwered until now. If QSSL is interested to
solve their deficiency in drivers they should
provide a detailed and consistent documentation
about the appropriate interfaces.
Yes, there is huge work done but there are still
annoying information leaks if you trying to 'do
your own thing'. (see the Eric questions ..)

As the author of that initial posting, I will chime in exactly once in
this sub-thread.

[ clip .. ]
And, for the record, the Neutrino solution is better, IMHO. If anyone
should be stealing driver models, it is linux from Neutrino. Not the
other way around.

My last 2 cencts:

Using the same LIBRARY STANDARD ( for instance the
POSIX standard, LINUX 'lib standard' or QNX4 'lib
standard' ) for drivers doesn't mean that the
drivers must share the same driver model ... e.g.
LINUX drivers and NTO drivers are completely
different but they are using the same standard for
POSIX threads.

We have the same situation if we take the LINUX or
QNX4 PCI library definitions as a standard. IMHO
...we are just winners when we follow IT standards
....

Armin

[Igor Kovalenko]

Not sure about PHYSICAL, but if you don't ftruncate() normal region you'll
get SIGBUS referencing it.
- igor

<pgraves@qnx.com> wrote in message news:8vuck7$eg5$1@nntp.qnx.com...

Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
SNIP

Here's the code I use:

fd = shm_open("/quackfb", O_RDWR | O_CREAT, 0777);
if (-1 == fd)
perror("shm_open");

if (-1 == ftruncate(fd, theSize))
perror("ftruncate");

if (-1 == shm_ctl(fd, SHMCTL_PHYS, thePhysicalAddr, theSize))
perror("shm_ctl");

When I run this from my driver, I get an error from shm_ctl
(errno=ENOSYS).


Not sure if this had been answered later in this thread alreay,
but you can not call shm_ctl on a shared memory object that is flagged
special (think it's special at least). The call to ftruncate will
flag it as special. If you drop the ftruncate it should work better.
This also means you can only call shm_ctl once as well.

-Peter

[Guest]

If you don't use the shm_ctl you will. But the shm_ctl will
do the resize for you based on the size you pass it. But
once you call ftruncate you can no longer call shm_ctl, and
you can only call shm_ctl once.

-Peter

Igor Kovalenko <kovalenko@home.com> wrote:

Not sure about PHYSICAL, but if you don't ftruncate() normal region you'll
get SIGBUS referencing it.
- igor

pgraves@qnx.com> wrote in message news:8vuck7$eg5$1@nntp.qnx.com...
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
SNIP

Here's the code I use:

fd = shm_open("/quackfb", O_RDWR | O_CREAT, 0777);
if (-1 == fd)
perror("shm_open");

if (-1 == ftruncate(fd, theSize))
perror("ftruncate");

if (-1 == shm_ctl(fd, SHMCTL_PHYS, thePhysicalAddr, theSize))
perror("shm_ctl");

When I run this from my driver, I get an error from shm_ctl
(errno=ENOSYS).


Not sure if this had been answered later in this thread alreay,
but you can not call shm_ctl on a shared memory object that is flagged
special (think it's special at least). The call to ftruncate will
flag it as special. If you drop the ftruncate it should work better.
This also means you can only call shm_ctl once as well.

-Peter

[btr]

Hi

Only core OS services reside in "kernel"
address space -- everything else, including device drivers, reside in
"process" or "user" address space.

With InterruptAttach(), the driver's "handler" function is called directly
by the kernel. Since it's running in kernel space, the hander is severely
restricted in what it can do. From within this handler, it isn't safe to
call most of the C library functions. Also, if you spend too much time in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt
handler
can negatively affect the system's realtime responsiveness.

As I understand, this is potential way to kill all system through any device
driver, not?
Because of huge amount of hardware QSSL can't check any driver from hardware
vendors.
Security is made a sacrifice to performance in this case, right?
Can you provide some comparison in performance of two interrupt-handling
methods?

With best regards
Boris

[Igor Kovalenko]

"btr" <btr_@mail.ru> wrote in message news:9191lj$55r$1@inn.qnx.com...

Hi

Only core OS services reside in "kernel"
address space -- everything else, including device drivers, reside in
"process" or "user" address space.

With InterruptAttach(), the driver's "handler" function is called
directly
by the kernel. Since it's running in kernel space, the hander is
severely
restricted in what it can do. From within this handler, it isn't safe to
call most of the C library functions. Also, if you spend too much time
in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt
handler
can negatively affect the system's realtime responsiveness.

As I understand, this is potential way to kill all system through any
device
driver, not?
Because of huge amount of hardware QSSL can't check any driver from
hardware
vendors.
Security is made a sacrifice to performance in this case, right?
Can you provide some comparison in performance of two interrupt-handling
methods?

Downside of InterruptAttachEvent() method is that event will be delivered
and your thread scheduled to run even if the event is not really yours
(since interrupts can be shared on PCI). A real interrupt handler could
check the source of interrupt and return value based on that check.

- igor

[David Donohoe]

btr <btr_@mail.ru> wrote:

Hi

Only core OS services reside in "kernel"
address space -- everything else, including device drivers, reside in
"process" or "user" address space.

With InterruptAttach(), the driver's "handler" function is called directly
by the kernel. Since it's running in kernel space, the hander is severely
restricted in what it can do. From within this handler, it isn't safe to
call most of the C library functions. Also, if you spend too much time in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt
handler
can negatively affect the system's realtime responsiveness.

As I understand, this is potential way to kill all system through any device
driver, not?
Because of huge amount of hardware QSSL can't check any driver from hardware
vendors.
Security is made a sacrifice to performance in this case, right?

Yes, a device driver can easily take down the system. However, an
app or driver which wants to bang at hardware, or attach an interrupt
handler, needs to run at "root" privilidge. It is presumed that "root"
will only install well-behaved drivers on the system.

Can you provide some comparison in performance of two interrupt-handling
methods?

The InterruptAttach() method will have a much lower latency, since
in the case of InterruptAttachEvent(), you have to wait 'til your
thread gets scheduled, before you can respond to the interrupt.

The exact latencies obviously vary from machine to machine. The
system load (whether there are higher-priority interrupts being
serviced), and the priority of the thread handling an
interrupt event also come into play.

Some devices (e.g. a serial device with a small (or no) FIFO), might use
InterruptAttach(), and retrieve the data from the hardware and buffer
it in the interrupt handler, to be processed later by higher-level
software. This would necessary to avoid overruns and data loss,
if there was not time to retrieve the data from the hardware,
before a user-level thread could be scheduled.

With best regards
Boris

[sachin]

Hi,
I read this aricle. Article is very much informative. But it does not
talk about DMAs.
Either ISA or PCI. I'm looking for API to convert my virtual address to
physical address
which I can use to initiate DMA over PCI from a PCI device.

-Sachin
"David Donohoe" <ddonohoe@qnx.com> wrote in message
news:93nb49$68u$1@nntp.qnx.com...

btr <btr_@mail.ru> wrote:
Hi

Only core OS services reside in "kernel"
address space -- everything else, including device drivers, reside in
"process" or "user" address space.

With InterruptAttach(), the driver's "handler" function is called
directly
by the kernel. Since it's running in kernel space, the hander is
severely
restricted in what it can do. From within this handler, it isn't safe
to
call most of the C library functions. Also, if you spend too much time
in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt
handler
can negatively affect the system's realtime responsiveness.

As I understand, this is potential way to kill all system through any
device
driver, not?
Because of huge amount of hardware QSSL can't check any driver from
hardware
vendors.
Security is made a sacrifice to performance in this case, right?

Yes, a device driver can easily take down the system. However, an
app or driver which wants to bang at hardware, or attach an interrupt
handler, needs to run at "root" privilidge. It is presumed that "root"
will only install well-behaved drivers on the system.

Can you provide some comparison in performance of two interrupt-handling
methods?

The InterruptAttach() method will have a much lower latency, since
in the case of InterruptAttachEvent(), you have to wait 'til your
thread gets scheduled, before you can respond to the interrupt.

The exact latencies obviously vary from machine to machine. The
system load (whether there are higher-priority interrupts being
serviced), and the priority of the thread handling an
interrupt event also come into play.

Some devices (e.g. a serial device with a small (or no) FIFO), might use
InterruptAttach(), and retrieve the data from the hardware and buffer
it in the interrupt handler, to be processed later by higher-level
software. This would necessary to avoid overruns and data loss,
if there was not time to retrieve the data from the hardware,
before a user-level thread could be scheduled.

With best regards
Boris

[Robert Krten]

sachin <vaidyasd@hotmail.com> wrote:

Hi,
I read this aricle. Article is very much informative. But it does not
talk about DMAs.
Either ISA or PCI. I'm looking for API to convert my virtual address to
physical address
which I can use to initiate DMA over PCI from a PCI device.

mphys ()

returns a PA given a VA. If you need multiple page-sized chunks, run mphys()
over page-sized-aligned chunks of memory and return multiple PAs.

Ie, if page-size == 4k, and you have a 10k chunk, knowing that the PA maps
to 4k sized PA chunks, divide the 10k chunk into 3 or 4 (depending on alignment)
4k-aligned chunks of VA space. Then run mphys() on the start block of each
4k chunk. This will return the start of each 4k-sized PA. Optionally coallesce
the multiple 4k PA chunks into larger chunks if they're contiguous.

Cheers,
-RK

-Sachin
"David Donohoe" <ddonohoe@qnx.com> wrote in message
news:93nb49$68u$1@nntp.qnx.com...
btr <btr_@mail.ru> wrote:
Hi

Only core OS services reside in "kernel"
address space -- everything else, including device drivers, reside in
"process" or "user" address space.

With InterruptAttach(), the driver's "handler" function is called
directly
by the kernel. Since it's running in kernel space, the hander is
severely
restricted in what it can do. From within this handler, it isn't safe
to
call most of the C library functions. Also, if you spend too much time
in
the handler, other processes and interrupt handlers of a lower or equal
priority won't be able to run. Doing too much work in the interrupt
handler
can negatively affect the system's realtime responsiveness.

As I understand, this is potential way to kill all system through any
device
driver, not?
Because of huge amount of hardware QSSL can't check any driver from
hardware
vendors.
Security is made a sacrifice to performance in this case, right?

Yes, a device driver can easily take down the system. However, an
app or driver which wants to bang at hardware, or attach an interrupt
handler, needs to run at "root" privilidge. It is presumed that "root"
will only install well-behaved drivers on the system.

Can you provide some comparison in performance of two interrupt-handling
methods?

The InterruptAttach() method will have a much lower latency, since
in the case of InterruptAttachEvent(), you have to wait 'til your
thread gets scheduled, before you can respond to the interrupt.

The exact latencies obviously vary from machine to machine. The
system load (whether there are higher-priority interrupts being
serviced), and the priority of the thread handling an
interrupt event also come into play.

Some devices (e.g. a serial device with a small (or no) FIFO), might use
InterruptAttach(), and retrieve the data from the hardware and buffer
it in the interrupt handler, to be processed later by higher-level
software. This would necessary to avoid overruns and data loss,
if there was not time to retrieve the data from the hardware,
before a user-level thread could be scheduled.

With best regards
Boris

--
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

[David Donohoe]

sachin <vaidyasd@hotmail.com> wrote:

Hi,
I read this aricle. Article is very much informative. But it does not
talk about DMAs.
Either ISA or PCI. I'm looking for API to convert my virtual address to
physical address
which I can use to initiate DMA over PCI from a PCI device.

That reminds me, I was planning a second article

You can get the physical address with mem_offset64().

There may also be a translation between addresses on the CPU bus
and those on the PCI bus; look at the CpuBmstrTranslation
member of the pci_dev_info structure. (You can get away with
ignoring it on x86, though, since it's zero).

Dave