Article:Talking to hardware under QNX Neutrino

bridged with qdn.public.articles
Warren Peece

Re: Article:Talking to hardware under QNX Neutrino

Post by Warren Peece » Sun Nov 26, 2000 9:51 pm

"Armin Steinhoff" <A-Steinhoff@web_.de> wrote in message
news:3A2170AC.627F6CDA@web_.de...

| You are missing my point completely ... here some
| infos especially for you.
|
| From the article "QNX Opens Platform for
| Developers / OTTAWA, April 24, 2000":
|
| "In addition, QNX Software has integrated a high
| level of Linux compatibility into its new platform
| so that Linux developers will feel right at home.
| As a result, e-device builders can now leverage
| the enormous pool of Linux talent, while building
| their products on reliable, market-proven QNX
| technology."

Okay maybe I'm partially blind, but where in there does it say anything about
being able to compile Linux device drivers unaltered? I suppose you could
argue that simply using the GNU compiler and tools and supporting essentially
the same library calls and POSIX stuff is not really a "high" level of Linux
compatibility, but rather "high level" Linux compatibility, but I would have to
say that there exists a high level of compatibility. If you choose to read
into that paragraph "...and all of the device driver stuff is the same as Linux
too" then go right ahead, but it's a silly notion and that quote does not
support your position in the least.

| There are _two_ header types.... that means there
| are at least 2 standard structures of the single
| PCI standard !

Now you're simply digressing and nitpicking, trying to obfuscate the fact that
you're not making any sense. Regardless of how many individual structures you
feel are in the PCI spec (one could argue that each field is a structure in
itsself, therefore proving your statement wrong, but that would be pointless
and inane, like this entire sub-thread), you're still talking about the copy in
PCI address space. So what was your point again? Oh yes, it was just to never
give in on anything and have to admit that someone else may be right.

| > QNX has chosen to load that
| > data from PCI space to memory into structures of their design.
|
| I can live with it as long as their design is well
| documented ...

And there lies the only potentially valid point you've made in this whole
twisted sub-thread, that perhaps the documentation could be made clearer. It
would certainly seem much more pleasant to me if you would have just said so in
the first place instead of fabricating silly, confrontational accusations about
not following standards and duties towards compatibility AT THE DEVICE DRIVER
LEVEL with other operating systems. Please try to be more succinct so we can
decipher what your real issues are in the future.

| > Then you should stop using it and go bitch somewhere else.
|
| I don't discuss on that impossible level.

What do you mean? That's the only level you seem to want to discuss things on.
You're the one that's unhappy and complaining about things that seem totally
logical to me. If these things that obviously aren't going to change and have
been a lot more well thought out by more people on more levels than you could
ever match make you so unhappy that you feel the need to argue incessantly then
perhaps you should look to a different product that's more to your liking.
It's like someone who complains about the weather where they are- their only
real option is to move. There are many people reading these newsgroups who'd
love to help you with anything you should require, but going on and on about
things that not only can't change but shouldn't change is just annoying and
there's nothing anyone can do for you so what's the point of doing it?

-Warren

David Donohoe

Re: Article:Talking to hardware under QNX Neutrino

Post by David Donohoe » Mon Nov 27, 2000 12:34 am

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

It's a pity you do not like how we've implemented and documented
our PCI library calls.

If you are in fact trying to write a device driver, and are running into
difficulties, please decribe specific the problems you are having, and people
will be happy to help you resolve them.
David Donohoe wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Debbie Kane wrote:

Talking to hardware under QNX Neutrino
By Dave Donohoe, QNX Software Systems Ltd.
http://support.qnx.com/support/articles ... dware.html

[ clip ... ]

#include
#include
#include

main()
{
struct pci_dev_info info;

-------------------------------------------------------------------------------
The struct 'pci_dev_info' is not LINUX compatible!

I think it was mentioned somewhere in the article that writing
drivers for QNX was different than for more traditional UNIX style
operating systems.

/ rant mode ON

The semantic and documentation of the PCI library
calls has nothing to do with the structure of a
driver! What I'm expecting is that the QNX6 PCI
calls are at least compatible with QNX4 ... even
if QSSL doesn't care about the 'rest' of the UNIX
world!!

I'm missing a clear description of the definion of
the struct pci_dev_info!!

The fields in this structure are described in the pci_attach_device()
docs.

Yes ... but I would say the components of that
structure are raw commented.

What is e.g. the CpuIoTranslation a.s.o ?

As the docs say:
CPU to PCI translation value (pci_addr = cpu_addr - translation)

The docs doesn't define what the pci_addr,
cpu_addr and the translations are.

Suggests to me that for a given IO address in PCI space,
you could derive the corresponding address in CPU IO address
space by adding CpuIoTranslation to the PCI address.

I know address translations only in the context of
PCI bridges ...

What is e.g. the PciBaseAddress ?? Is it the
contents of a Base Address Register ??

The six elements in the PciBaseAddress array correspond to the
six PCI Base Address registers,

So and why the different names ... the rest of the
world is calling the PCI Base Address Registers by
its name as used in the PCI configuration address
space structure.

in a PCI devices configuration
space. The addresses in PciBaseAddress[] are what the configuration
space registers would are programmed with. The addresses in the
CpuBaseAddress array are the addresses which the CPU would use
to access the device. You would pass the CpuBaseAddress versions
to mmap_device_memory.

So the CpuBaseAddress is represented by the bits
31:4 (memory) or 31:2 (I/O) of the Base Address
Registers(?).

Note that on x86 systems, there is a one-to-one mapping between
the CPU and PCI versions of the base address registers.

Are you sure? I believe you have to mask out at
least the 4 or 2 least significant bits. (see the
QNX4 macro PCI_MEM_ADDR() ... I hope you know it)

Hence,
the CpuIoTranslation, CpuMemTranslation, and CpuBmstrTranslation
members of the pci_dev_info structure would be zero, on an x86
system.

Important to know. Where can I find these
translation values in the PCI configuration
address space ?

IMHO, if QSSL prefers to use non standard PCI
structures ... then they should
provide a clear decription of those structures!

Which "standard PCI structures" are you talking about?

There is only one PCI standard ... do you know
others?

Perhaps you are referring to the standard PCI configuration
space layout, which correlates to the _pci_config_regs
structure in /usr/include/hw/pci.h?

I refer to the PCI header type 00h and 01h.

/ rant mode OFF

BTW .. there are not only standards, there is also
a product line with a design history and this must
be attended in order to provide compatibility and
portability ... at least between QNX4 and QNX6.

I'm not very happy with the _dotted_ product line
of QSSL.

Armin

Eric Berdahl

Re: Article:Talking to hardware under QNX Neutrino

Post by Eric Berdahl » Mon Nov 27, 2000 3:24 am

In article <8vk3dj$efc$1@nntp.qnx.com>, David Donohoe
<ddonohoe@qnx.com> wrote:
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
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).

So, I'm still stuck. It appears as if shm_ctl is not implemented in
Neutrino. Am I missing something, or is there another mechanism I
should
be using to map my card into a client's address space?

You're not running it as root, are you ;-)

Non-privilidged apps are not allowed access to raw physical memory.
Yup. The code above, which is returning the errors, is absolutely
running as root. I have previously discovered empirically that things
link mmap_device_memory don't work unless the process has root
priviledges. This makes some sense -- you don't want just anyone being
able to set up hardware access.

So, yes that code runs as root. It still returns an error (errno=ENOSYS).
I think the error codes returned by this function are bogus.
No matter what the error is, it seems to return "Function not
implemented".
I've wondered about that. It certainly seems consistent with everything
I'm seeing. However, it also makes it rather difficult to discern one
error from another.
It really should have said "Permission denied".
I think not. As I said above, the program runs as root. However, I do
believe that a different error should be returned, I just can't figure
out which one.
You should also omit the call to ftruncate, above.
Ok. I assume that the shm_ctl call will resize the shared memory area,
yes?

BTW, I get the same behavior with or without the ftruncate call. I don't
know if that makes a difference to your analysis, but there it is.
Also, note that you can only do the shm_ctl once in the lifetime of the
object. If you need to modify/grow/shrink the object, you will need
to shm_unlink it, and re-create it.
Right. This is something that I expect to do in the driver once as part
of the driver's startup code. No need to change the physical base
address or size of the area later.

Other suggestions? Please? I'm not sure what to try next.

Thanks in advance,
Eric

Armin Steinhoff

Re: Article:Talking to hardware under QNX Neutrino

Post by Armin Steinhoff » Mon Nov 27, 2000 7:19 am

David Donohoe wrote:
Armin Steinhoff <A-Steinhoff@web_.de> wrote:

It's a pity you do not like how we've implemented and documented
our PCI library calls.
David ,
my criticism has nothing to do wether I 'like'
your implementations or not.

QSSL wrote in the article "QNX Opens Platform for
Developers / OTTAWA, April 24, 2000":

"In addition, QNX Software has integrated a high
level of Linux compatibility into its new platform
so that Linux developers will feel right at home."

The PCI library calls are dealing with the same
PCI standard, regardless if I use
LINUX or QNX4 ... so there are no reasons to
introduce a set of proprietary library calls which
are incompatible to QNX4 and LINUX.

The documentation of these proprietary PCI library
calls and their related structures doesn't show
clearly their relationship to the standard PCI
headers.
Also the semantic of many components of the new
introduced structures are not very clear.

So why should "Linux developers will feel right at
home." ?
If you are in fact trying to write a device driver, and are running into
difficulties,
Yes, in fact I did and do it ... but I don't have
any problems. My intention is to avoid any
confusion producted by the proprietary
implementation of the PCI service calls.
please decribe specific the problems you are having, and people
will be happy to help you resolve them.
I would be happy if QSSL would handle
compatibility issues more carefully.

Armin

Armin Steinhoff

Re: Article:Talking to hardware under QNX Neutrino

Post by Armin Steinhoff » Mon Nov 27, 2000 7:23 am

Warren Peece wrote:
[ clip ..]

Okay maybe I'm partially blind,
Not your problem ... learn to handle criticism or
"go bitch somewhere else".

Armin

Armin Steinhoff

Re: Article:Talking to hardware under QNX Neutrino

Post by Armin Steinhoff » Mon Nov 27, 2000 9:31 am

Eric Berdahl wrote:
In article <8vgjsj$q6j$1@inn.qnx.com>, "Debbie Kane" <debbie@qnx.com
wrote:

2. Memory-mapped resources
For some devices, registers are accessed via regular memory operations.
To
gain access to a device's registers, you need to map them to a pointer in
the driver's virtual address space. This can be done by calling
mmap_device_memory().

volatile uint32_t *regbase; /* device has 32-bit registers */

regbase = mmap_device_memory(NULL, info.BaseAddressSize[0],
PROT_READ|PROT_WRITE|PROT_NOCACHE, 0,
info.CpuBaseAddress[0]);

Note that we specified the PROT_NOCACHE flag. This ensures that the CPU
won't defer or omit read/write cycles to the device's registers, nor will
it
deliver the reads or writes to the registers in a different order than
the
driver issued them.

This is good for allowing a driver to access its device's registers, but
what about something like a video card's frame buffer? The difference is
that it is a common practice to memory map the frame buffer into the
client's address space so the client application can render directly
into the frame buffer. On other operating systems (e.g. linux), this can
be done by mmap'ing the device:

fd = open("/dev/mypcicard", O_RDWR);
base = mmap(NULL, myFrameBufferSize,
PROT_NOCACHE | PROT_READ | PROT_WRITE,
0, fd, 0 /* start of frame buffer */);
There must be a pair of BaseAddressSize[] /
CpuBaseAddress[] which is referencing the frame
buffer of your device. So it should be possible to
use mmap() or
mmap_device_memory().

Armin

Mario Charest

Re: Article:Talking to hardware under QNX Neutrino

Post by Mario Charest » Mon Nov 27, 2000 12:54 pm

Warren,

Could you send me your email address I've lost it ;-)

- Mario

Chris McKillop

Re: Article:Talking to hardware under QNX Neutrino

Post by Chris McKillop » Mon Nov 27, 2000 2:53 pm

Armin Steinhoff <A-Steinhoff@web_.de> wrote:
"In addition, QNX Software has integrated a high
level of Linux compatibility into its new platform
so that Linux developers will feel right at home."
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.
The PCI library calls are dealing with the same
PCI standard, regardless if I use
LINUX or QNX4 ... so there are no reasons to
introduce a set of proprietary library calls which
are incompatible to QNX4 and LINUX.
Well, I am pretty sure that the QNX4 calls are different then the Linux
calls so I am confused by this statement. It would seem to me that under
this argument we could not win? As a programmer who used Neutrino to do
a PCI based device driver with nothing but the QNX2000 beta and the helpviewer
I thought that the pci_*() functions were very logical and very easy to deal
with - now that I work @ QSSL this hasn't changed much. :)

Given that QNX4 and Linux (and FreeBSD, etc, etc) have different PCI space
interfaces why not just make a library? The end goal is the same on all
platforms. In fact, I made such a library for a talk Sebastien gave @
ESC in Septemeber. It provided a simple framework for doing a character
device on both Linux and QNX - using the same core source for doing the
"real" work. It took me about 1 night. If someone actually spent some
serious time on it one could provide a framework that allowed more complex
drivers to be built.

chris

--
cdm@qnx.com "The faster I go, the behinder I get."
Chris McKillop -- Lewis Carroll --
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Warren Peece

Re: Article:Talking to hardware under QNX Neutrino

Post by Warren Peece » Mon Nov 27, 2000 3:38 pm

"Armin Steinhoff" <A-Steinhoff@web_.de> wrote in message
news:3A220C07.8060C2C6@web_.de...
Warren Peece wrote:

[ clip ..]

Okay maybe I'm partially blind,

Not your problem ... learn to handle criticism or
"go bitch somewhere else".

Armin
Ah, but you see Armin it's apparently you that's blind. Because what I was
saying was that I failed to find anywhere in that paragraph where it said
that QNX's device driver model was identical to the one used in Linux,
therefore if you were right then I must be blind. I wasn't admitting that
you were right and I just missed it the first time, it's still not there,
and it never was, and it never will be. Fortunately for me and
unfortunately for your argument, I'm not blind, and that paragraph in no way
insinuates anything about QNX6 compatibility with Linux at the device driver
level no matter how much you twist the meaning of what I say.

So here we have an instance of you quoting some advertising in support of
your claim that QNX is not following through with their promises of Linux
compatibility, and that advertising doesn't support your claim at all. Now
instead of either finding something that really does support your claim or
backing off and saying that perhaps you misunderstood what was intended by
that advertising, you decide to accuse me of not taking criticism very well.
It appears that perhaps you should consider your own advice.

The mechanics of your English are excellent, so I find it extremely
frustrating that you repeatedly fail to grasp what appear to be the
extremely simple concepts between Linux compatibility and being exactly like
Linux down to the header files at the device driver level. QNX in no way
insinuated that would be the case, and in fact went out of their way to say
that writing QNX device drivers is substantially different than on other
systems. They consider those differences, as do I, a major benefit. So why
in the world do you persist in claiming that they said otherwise? It's pure
fantasy and highlights a glaring lack of understanding on your part. Even
after repeatedly having it explained to you, you continue to act as though
you have some sort of a valid point. In this instance you do not have a
valid point, and your persistance in asserting that you do is costing your
credibility dearly.

-Warren "asbestos longjohns" Peece

Armin Steinhoff

Re: Article:Talking to hardware under QNX Neutrino

Post by Armin Steinhoff » Mon Nov 27, 2000 4:30 pm

Chris McKillop wrote:
Armin Steinhoff <A-Steinhoff@web_.de> wrote:

"In addition, QNX Software has integrated a high
level of Linux compatibility into its new platform
so that Linux developers will feel right at home."


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 ..)
The PCI library calls are dealing with the same
PCI standard, regardless if I use
LINUX or QNX4 ... so there are no reasons to
introduce a set of proprietary library calls which
are incompatible to QNX4 and LINUX.


Well, I am pretty sure that the QNX4 calls are different then the Linux
calls so I am confused by this statement.
"incompatible to QNX4 and LINUX" means for me
'incompatible with QNX4' and 'incompatible with
LINUX' ... so in what direction are you guys
going?
It would seem to me that under
this argument we could not win? As a programmer who used Neutrino to do
a PCI based device driver with nothing but the QNX2000 beta and the helpviewer
I thought that the pci_*() functions were very logical and very easy to deal
with - now that I work @ QSSL this hasn't changed much. :)
I don't see problems to handle the pci_* functions
.... if the docs are consistent.
An expierenced developer would 'interpret' the
provided structures ( with some trial and errors
probbably) rigth ... but what about the PCI
newbies ??
Given that QNX4 and Linux (and FreeBSD, etc, etc) have different PCI space
interfaces why not just make a library? The end goal is the same on all
platforms. In fact, I made such a library for a talk Sebastien gave @
ESC in Septemeber. It provided a simple framework for doing a character
device on both Linux and QNX - using the same core source for doing the
"real" work. It took me about 1 night. If someone actually spent some
serious time on it one could provide a framework that allowed more complex
drivers to be built.
Are there any vaible approaches possible with
UNIX98 standard or UDI ?

Armin

greenboy

Re: Article:Talking to hardware under QNX Neutrino

Post by greenboy » Mon Nov 27, 2000 5:02 pm

Armin Steinhoff <A-Steinhoff@web_.de> :
"In addition, QNX Software has integrated a high level
of Linux compatibility into its new platform so that
Linux developers will feel right at home."
Jeez, Armin, give it a rest. I have to agree with the other
gentleman here; you are way off base.

--

<-- greenboy ---<<<

Warren Peece

Re: Article:Talking to hardware under QNX Neutrino

Post by Warren Peece » Mon Nov 27, 2000 5:23 pm

"Armin Steinhoff" <A-Steinhoff@web_.de> wrote in message
news:3A228C34.48287B8F@web_.de...

| Chris McKillop wrote:
| >
| > Armin Steinhoff <A-Steinhoff@web_.de> wrote:
| > >
| > > "In addition, QNX Software has integrated a high
| > > level of Linux compatibility into its new platform
| > > so that Linux developers will feel right at home."
| > >
| >
| > 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 I said before Armin, yes I agree that documentation can almost always be
made clearer. Instead of simply saying that the documentation needs work,
please take the time to point out the individual areas that leave questions in
your mind so the documentation folks can review those sections. This will be
greatly appreciated by the staff and the rest of us as well.

As for your response to Chris, you failed to grasp his point. He is responding
to your use of that quote as proof that QNX is not providing Linux
compatibility at the device driver level. Funny thing is, he's saying exactly
what I said, that the quote does not in any way specify 100% compatibility down
to the device driver level. So now you have it from a QNX staffer that this
was never their intent. If that is still what you truly believe it to say,
then you are mistaken. So you cannot dismiss his point by referring to Eric
having problems with the documentation. Doing so does not make any sense. You
responded to point "A" by pointing out a different problem we'll call "B", then
act as if you have addressed point "A" when in reality you have not.

| > >
| > > The PCI library calls are dealing with the same
| > > PCI standard, regardless if I use
| > > LINUX or QNX4 ... so there are no reasons to
| > > introduce a set of proprietary library calls which
| > > are incompatible to QNX4 and LINUX.
| > >
| >
| > Well, I am pretty sure that the QNX4 calls are different then the Linux
| > calls so I am confused by this statement.
|
| "incompatible to QNX4 and LINUX" means for me
| 'incompatible with QNX4' and 'incompatible with
| LINUX' ... so in what direction are you guys
| going?

How about if I lay it out for you. "QNX6 is not, will not be, and was never
intended to be compatible with either QNX4 or Linux at the device driver
level." If you don't understand that, then it's no wonder you're having
problems. The direction they're going is what they feel is the best direction
for QNX6, which is in my opinion better than QNX4 and Linux and would only have
been hampered if they had attempted to build in compatibility with either down
at the very lowest levels.

| > It would seem to me that under
| > this argument we could not win? As a programmer who used Neutrino to do
| > a PCI based device driver with nothing but the QNX2000 beta and the
helpviewer
| > I thought that the pci_*() functions were very logical and very easy to
deal
| > with - now that I work @ QSSL this hasn't changed much. :)
|
| I don't see problems to handle the pci_* functions
| ... if the docs are consistent.
|
| An expierenced developer would 'interpret' the
| provided structures ( with some trial and errors
| probbably) rigth ... but what about the PCI
| newbies ??

If people do not understand the PCI specification then how can you expect them
to write a device driver? The fact of the matter is that a certain level of
expertise is necessary to write device drivers. You have it, I have it, if
there's someone who's just starting out, they can certainly ask us for help and
we will gladly provide it. Then they will also have it. This is of course not
an excuse for poor documentation, and I agree with you that every effort should
be made to thoroughly and completely document the entire interface.

-Warren

| > Given that QNX4 and Linux (and FreeBSD, etc, etc) have different PCI space
| > interfaces why not just make a library? The end goal is the same on all
| > platforms. In fact, I made such a library for a talk Sebastien gave @
| > ESC in Septemeber. It provided a simple framework for doing a character
| > device on both Linux and QNX - using the same core source for doing the
| > "real" work. It took me about 1 night. If someone actually spent some
| > serious time on it one could provide a framework that allowed more complex
| > drivers to be built.
|
| Are there any vaible approaches possible with
| UNIX98 standard or UDI ?
|
| Armin

Eric Berdahl

Re: Article:Talking to hardware under QNX Neutrino

Post by Eric Berdahl » Mon Nov 27, 2000 7:06 pm

In article <3A222A0C.6DC9BAD5@web_.de>, Armin Steinhoff
<A-Steinhoff@web_.de> wrote:
Eric Berdahl wrote:
This is good for allowing a driver to access its device's registers,
but
what about something like a video card's frame buffer? The difference
is
that it is a common practice to memory map the frame buffer into the
client's address space so the client application can render directly
into the frame buffer. On other operating systems (e.g. linux), this
can
be done by mmap'ing the device:

fd = open("/dev/mypcicard", O_RDWR);
base = mmap(NULL, myFrameBufferSize,
PROT_NOCACHE | PROT_READ | PROT_WRITE,
0, fd, 0 /* start of frame buffer */);


There must be a pair of BaseAddressSize[] /
CpuBaseAddress[] which is referencing the frame
buffer of your device. So it should be possible to
use mmap() or
mmap_device_memory().
Yes, if one is root one can do that very easily. The problem I was
having was allowing a non-root process to map that same memory area with
the driver (a root process) providing whatever help was necessary. The
trouble was finding out what "whatever help was necessary" meant.

Eric Berdahl

Re: Article:Talking to hardware under QNX Neutrino

Post by Eric Berdahl » Mon Nov 27, 2000 7:16 pm

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.

I have seen QSSL's advertising about linux compatibility for QNX and
Neutrino. I'm also a driver developer and I never once considered that
drivers would be portable from linux to Neutrino. Never. If they were, I
wouldn't be using Neutrino. Linux drivers run as modules of the kernel.
The fact that Neutrino drivers do not is a huge benefit to driver
developers. Linux drivers run with the scheduler completely turned off.
The fact that Neutrino drivers are full fledged threaded processes, with
the scheduler doing its thing all the time is great.

The linux kernel is fine for what the linux kernel does. Neutrino is
fine for what Neutrino does. Driver people generally understand that
drivers need to be written for the kernel, not the high-level APIs.
Driver people also generally understand that no two distinct kernels in
the world have the same driver model except in extraordinary
circumstances.

Furthermore, my posting was not meant to imply that Neutrino should or
should not implement their driver model to be like linux. Rather, I had
a specific problem: how to map a part of my card's memory into a
non-root client process with the tacit approval of the driver. I used
our existing linux driver's solution as an example of how we solved the
problem on that operating system. I also asked if that solution was
appropriate in Neutrino. It was not. Thanks to the suggestions and
patience of several individuals at QSSL and elsewhere, I now have a
working solution in Neutrino.

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 two cents.
Eric

Guest

Re: Article:Talking to hardware under QNX Neutrino

Post by Guest » Mon Nov 27, 2000 7:28 pm

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

Post Reply

Return to “qdn.public.articles”