“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
