How to boot with -ptcpip [was: netstat and route]

[system]

I just took a quick look at my older posix book (1993 spec) and
it looks like if <uinstd.h> does not define _POSIX_MAPPED_FILES
(section 2.9.3) that the system does not have to support the
memory mapped files option. I did a quick test and this constant
is not defined, so I believe that not supporting memory mapped
files fully does not make Neutrino non-posix.

-Peter


Maurizio Rossi <mrossi@system-group.it> wrote:

Please, Mr. Steinhoff and Mr.Berdahl,

can you post the POSIX specs regarding that this stuff MUST (or MUST NOT) be
supported for POSIX
compliancy?

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A24C965.4DE19A80@web_.de…


Eric Berdahl wrote:

In article <901lri$4dn$> 1@inn.qnx.com> >, “Igor Kovalenko”
Igor.Kovalenko@motorola.com> > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A23DFD9.FCD56DF3@web_.de…

Hi,

the following sequence of library calls can’t be
used with QNX6

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

The usage of the calls above is fully POSIX and
UNIX98 compliant … but it doesn’t work with
QNX6.

After suffering several years with the same
problem under QNX4 … is there a chance to get
for QNX6 a clean and compliant implementation of
the mmap call ??
Will QNX6 not be fully POSIX compliant ??


You’re effectively asking why can’t QNX6 have VM model used by modern
Unixes. It can, but it takes lot of development. Unixes have long
history
behind them and their VM evolved along the lines. QNX can’t just take
their
code. Or may be they can, but they don’t want it. It is a half million
lines
of code.

Now, if you just add MAP_NOSYNCFILE to flags in the above snippet, it
will
work, just without syncronization between memory and file. I think
this
has
been discussed a dozen times already. But yes, I want them to get it
fully
working too, eventually >

There’s another falacy with the above code. Notice that the thing you’re
mmap’ing is a device (a file descriptor opened from the /dev file
system).

That’s completely standard with UNIX systems …
that’s the reason why
‘cat /dev/fd0’ works.

Thus, you also need a driver written to support the mmap system
call.

No … you need just system services and not a
driver.

As such, I consider the above set of code to be outside the POSIX
standard, even though the actual calls involved (open and mmap) are
POSIX routines.

Your consideration is simply wrong.

POSIX does not define a driver model,

Huh … who is talking about driver models?

nor does it define that the above code MUST work.

It MUST work if the system claims to be fully
POSIX compliant.

It just happens to work for many UNIXes.

No … it just happens for POSIX compliant systems,
because POSIX isn’t bound to UNIX.

In QNX, you can
achieve the same effect through a similar mechanism (shm_open and mmap,
with the explicit approval of the driver involved).

You can always do your own thing … but we are
talking about POSIX compliancy.

Armin


Regards,
Eric

[Steve_Furr]

In article <berdahl-AC46D6.00260229112000@inn.qnx.com>,
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

In article <901lri$4dn$> 1@inn.qnx.com> >, “Igor Kovalenko”
Igor.Kovalenko@motorola.com> > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A23DFD9.FCD56DF3@web_.de…

Hi,

the following sequence of library calls can’t be
used with QNX6

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

The usage of the calls above is fully POSIX and
UNIX98 compliant … but it doesn’t work with
QNX6.

After suffering several years with the same
problem under QNX4 … is there a chance to get
for QNX6 a clean and compliant implementation of
the mmap call ??
Will QNX6 not be fully POSIX compliant ??


You’re effectively asking why can’t QNX6 have VM model used by modern
Unixes. It can, but it takes lot of development. Unixes have long history
behind them and their VM evolved along the lines. QNX can’t just take
their
code. Or may be they can, but they don’t want it. It is a half million
lines
of code.

Now, if you just add MAP_NOSYNCFILE to flags in the above snippet, it
will
work, just without syncronization between memory and file. I think this
has
been discussed a dozen times already. But yes, I want them to get it
fully
working too, eventually >

There’s another falacy with the above code. Notice that the thing you’re
mmap’ing is a device (a file descriptor opened from the /dev file
system). Thus, you also need a driver written to support the mmap system
call. As such, I consider the above set of code to be outside the POSIX
standard, even though the actual calls involved (open and mmap) are
POSIX routines.

The jargon for this is intrinsic vs. extrinsic portability. Armin’s
sample might be POSIX conforming and, therefore, intrinsically
portable, because it only uses POSIX API specifications.

Extrinsic compatibility refers to semantic information
outside of the API itself, such as parameter values. (e.g. file name
for an open, specific devices, etc.).

One might as well argue that a system that doesn’t support:

open("/dev/foo");
…

isn’t POSIX because /dev/foo is prevalent on a bunch of systems.

It’s good to remember that POSIX != Unix, nor, to the best of
my knowledge do any Unix standards go far in specifying devices, or
defining a device/kernel interface, so with mmap() in particular,
there is no guarantee that a device must support map requests
on any Unix (it is a part of the STREAMS API for SVR4 devices).

Not trying to be too trite here, but POSIX is not designed to
provide a complete specification of application and kernel
programming interfaces for Unix systems. One of the goals is
to allow differing implementations with performance/efficiency/space,
etc, trade-offs. This one reason why it has proven to be effective
in the embedded space. If 100% compatibility with POSIX and Unix
were critical, I would think one would lean more heavily toward
using Solaris, for example. Otherwise, QNX goes a long way
towards implementing the bulk of Unix features available, with
genuine reliability and realtime predicatability – an area where
most Unices conforming to POSIX .1c fail.

I can assure you, QNX developers would love to have a complete
VM system, driver interfaces and drivers in place that allowed
mapping files for any device, but it is a non-trivial exercise,
and it is complicated by the microkernel architecture.

POSIX does not define a driver model, nor does it define that the above
code MUST work. It just happens to work for many UNIXes. In QNX, you can
achieve the same effect through a similar mechanism (shm_open and mmap,
with the explicit approval of the driver involved).

Indeed. Even if QNX turned on the _POSIX_MAPPED_FILES feature test,
POSIX only mandates that mmap() will be able to map regular files.

Regards,
Eric

–

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.

[John_Doe]

A bunch of professional developers did it in their
spare time for LINUX …

Uhuh, and is Linux a microkernel message passing O/S, or is it
a conventional 1970’s style monolithic kernel for which the
implementation model for VM is well understood and has many
existing implementations to consult ?

[Steve_Furr]

In article <3A24C965.4DE19A80@web_.de>,
Armin Steinhoff <A-Steinhoff@web_.de> wrote:

Eric Berdahl wrote:

In article <901lri$4dn$> 1@inn.qnx.com> >, “Igor Kovalenko”
Igor.Kovalenko@motorola.com> > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A23DFD9.FCD56DF3@web_.de…

Hi,

the following sequence of library calls can’t be
used with QNX6

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

The usage of the calls above is fully POSIX and
UNIX98 compliant … but it doesn’t work with
QNX6.

After suffering several years with the same
problem under QNX4 … is there a chance to get
for QNX6 a clean and compliant implementation of
the mmap call ??
Will QNX6 not be fully POSIX compliant ??


You’re effectively asking why can’t QNX6 have VM model used by modern
Unixes. It can, but it takes lot of development. Unixes have long history
behind them and their VM evolved along the lines. QNX can’t just take
their
code. Or may be they can, but they don’t want it. It is a half million
lines
of code.

Now, if you just add MAP_NOSYNCFILE to flags in the above snippet, it
will
work, just without syncronization between memory and file. I think this
has
been discussed a dozen times already. But yes, I want them to get it
fully
working too, eventually >

There’s another falacy with the above code. Notice that the thing you’re
mmap’ing is a device (a file descriptor opened from the /dev file
system).

That’s completely standard with UNIX systems …
that’s the reason why
‘cat /dev/fd0’ works.

Thus, you also need a driver written to support the mmap system
call.

No … you need just system services and not a
driver.

As such, I consider the above set of code to be outside the POSIX
standard, even though the actual calls involved (open and mmap) are
POSIX routines.

Your consideration is simply wrong.

POSIX does not define a driver model,

Huh … who is talking about driver models?

nor does it define that the above code MUST work.

It MUST work if the system claims to be fully
POSIX compliant.

It just happens to work for many UNIXes.

No … it just happens for POSIX compliant systems,
because POSIX isn’t bound to UNIX.

In QNX, you can
achieve the same effect through a similar mechanism (shm_open and mmap,
with the explicit approval of the driver involved).

You can always do your own thing … but we are
talking about POSIX compliancy.

Gack! I just read this. Armin, please see my previous post.
I think you have assumed something that is a meta-spec issue and
should probably refresh your memory in terms of what is in the
specification if portability is a concern.

This happens to work for most Unix systems (not just happens, though)
because with SVR4 and above – and with BSD-derived VFS-based systems –
the driver model specifies a MAP_PAGE request.

POSIX is completely silent on this. It has nothing to do with
POSIX compliance.

What POSIX says is that mmap() will be supplied if the platform
defines the _POSIX_MAPPED_FILES or _POSIX_SHARED_MEMORY_OBJECTS
feature tests. Within this framework, mmap() will be able to
map regular files only if _POSIX_MAPPED_FILES is defined.
POSIX doesn’t say that mmap() will work with special files.

---

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.

[Steve_Furr]

In article <902qfm$b70$1@inn.qnx.com>,
Maurizio Rossi <mrossi@system-group.it> wrote:

Please, Mr. Steinhoff and Mr.Berdahl,

can you post the POSIX specs regarding that this stuff MUST (or MUST NOT) be
supported for POSIX
compliancy?

Refer to ISO/IEC 9945-1:1996 (IEEE 1003.1-1996).

It says:

(Section 12.2.1.2)

If at least one of {_POSIX_MAPPED_FILES} or {_POSIX_SHARED_MEMORY_OBJECTS}
is defined:

The function mmap() establishes a mapping between the address space
of the process and a memory object…

The remainder of the section defines legal parameters and their effect.

In appendix F, which defines considerations for the construction
of POSIX profiles, they provide further information.

(Section F.3.1)

{_POSIX_MAPPED_FILES}
The system supports the mapping of regular files into the process
address space.

Both this option and the {_POSIX_SHARED_MEMORY_OBJECTS} option
provide shared access to memory objects in the process address
space. The interfaces defined under this option provide the
functionality of existing practice for mapping regular files.
This functionality was deemed unnecessary, if not inappropriate,
for embedded systems applications, and hence, is provided under
this option. It should only be required if needed, but it
should not be prohibited.

(ibid)

{_POSIX_SHARED_MEMORY_OBJECTS}
The system supports the mapping of shared memory objects into the
process address space.

Both this option and the {_POSIX_MAPPED_FILES} option
provide shared access to memory objects in the process address
space. The interfaces defined under this option provide the
functionality of existing practice for shared memory objects.
This functionality was deemed appropriate for embedded systems
applications, and hence, is provided under this option. It should
only be required if needed, but it should not be prohibited.


Some information on the rationale:

The existing practice reference under mapped files indicates that
most Unix systems use the VM system to support cache for
the file system, and cache coherency is employed to support
demand paging. i.e. it is a fundamental component of the operating
system support for integrated VM support and demand paging of
code. Since the access is uniform, the practice developed of
allowing applications to map regular files as well – after all
it’s free – to enable performance improvements over I/O access.

Since VM (actually demand paging in the VM system) is not at all core
to embedded systems, the practice of mapping files isn’t necessary, and
possibly inappropriate.

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A24C965.4DE19A80@web_.de…


Eric Berdahl wrote:

In article <901lri$4dn$> 1@inn.qnx.com> >, “Igor Kovalenko”
Igor.Kovalenko@motorola.com> > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A23DFD9.FCD56DF3@web_.de…

Hi,

the following sequence of library calls can’t be
used with QNX6

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

The usage of the calls above is fully POSIX and
UNIX98 compliant … but it doesn’t work with
QNX6.

After suffering several years with the same
problem under QNX4 … is there a chance to get
for QNX6 a clean and compliant implementation of
the mmap call ??
Will QNX6 not be fully POSIX compliant ??


You’re effectively asking why can’t QNX6 have VM model used by modern
Unixes. It can, but it takes lot of development. Unixes have long
history
behind them and their VM evolved along the lines. QNX can’t just take
their
code. Or may be they can, but they don’t want it. It is a half million
lines
of code.

Now, if you just add MAP_NOSYNCFILE to flags in the above snippet, it
will
work, just without syncronization between memory and file. I think
this
has
been discussed a dozen times already. But yes, I want them to get it
fully
working too, eventually >

There’s another falacy with the above code. Notice that the thing you’re
mmap’ing is a device (a file descriptor opened from the /dev file
system).

That’s completely standard with UNIX systems …
that’s the reason why
‘cat /dev/fd0’ works.

Thus, you also need a driver written to support the mmap system
call.

No … you need just system services and not a
driver.

As such, I consider the above set of code to be outside the POSIX
standard, even though the actual calls involved (open and mmap) are
POSIX routines.

Your consideration is simply wrong.

POSIX does not define a driver model,

Huh … who is talking about driver models?

nor does it define that the above code MUST work.

It MUST work if the system claims to be fully
POSIX compliant.

It just happens to work for many UNIXes.

No … it just happens for POSIX compliant systems,
because POSIX isn’t bound to UNIX.

In QNX, you can
achieve the same effect through a similar mechanism (shm_open and mmap,
with the explicit approval of the driver involved).

You can always do your own thing … but we are
talking about POSIX compliancy.

Armin


Regards,
Eric

–

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.

[Warren_Peece1]

“Steve Furr” <furr@qnx.com> wrote in message news:903c7i$d67$1@nntp.qnx.com…

[ eloquent presentation of information deleted ]

| I can assure you, QNX developers would love to have a complete
| VM system, driver interfaces and drivers in place that allowed
| mapping files for any device, [ … ]

Speak for yourself, buddy! Even for my projects where I’m patiently awaiting
the arrival of >4G memory support for QNX6, I do NOT want VM and swapping. I
do NOT want to have memory mapped files. I do NOT want to have memory mapped
access to devices. I especially do NOT want to have to deal with all that
overhead across multiple nodes. If it’s going to add 4 CPU cycles of overhead
per call, or message or whatever unit of measure you choose, I’m against it and
I’ll ask for a “clean” uKernel implementation that doesn’t suffer from the
problem.

Since I have intimate knowledge of my projects, it’s my assertion that I am in
a much better position to make determinations about specific memory useage
requirements than anybody else. If I need to deal with mass storage because
not everything will fit in memory at the same time, I will design a schema
that’s optimum for my particular application, making the tradeoffs where
appropriate for my design goals. The idea that the O.S. designers, however
clever they may be, can design a generic universal virtual memory subsystem
that will perform at the same level as my custom tailored design for my
specific application is absurd. In my opinion, anybody who clamors for VM
availability either doesn’t care about or has absolutely no clue about
designing high-performance real-time systems. If you’re not designing
real-time systems then yeah, memory mapped files are fun to play with, and on
AIX perhaps you may even see an increase in disk throughput. I know I did, up
until every damn thing on the system was swapped to disk, then the two-way H70
crawled like a Timex Sinclair (now that’s slow!).

Suffice it to say I use QNX because of its virtues. It “gets out of your way”
when you need it to, and doesn’t bog you down with needless system overhead.
Don’t take this wrong, but remember how DOS let you pretty much take over the
entire machine and do whatever you pleased as long as you didn’t stomp on
something critical? QNX gives you a lot of that same freedom, plus a whole
suite of available functionality that you can use, ignore, or enhance at your
discretion. It just doesn’t get much better than that. All of those who
persist in trying to turn QNX6 into Linux should simply go use Linux, because
the two systems are fundamentally different beasts and will never provide
identical functionality. It would be a true shame indeed if QNX actually did
decide to shackle their O.S. to make it “the same as what everybody else has
done before”.

Okay I’ll go away now

-Warren

[Steve_Furr]

In article <903gdk$1qv$1@inn.qnx.com>, Warren Peece <warren@nospam.com> wrote:

“Steve Furr” <> furr@qnx.com> > wrote in message news:903c7i$d67$> 1@nntp.qnx.com> …

[ eloquent presentation of information deleted ]

| I can assure you, QNX developers would love to have a complete
| VM system, driver interfaces and drivers in place that allowed
| mapping files for any device, [ … ]

Speak for yourself, buddy! Even for my projects where I’m patiently awaiting
[snip]

Whoa, Peace Warren,

You are eloquently pointing one of the major difficulties in allowing
uniform application of such techniques for the benefit of applications.
As the rationale said, mapped files are likely inappropriate for
embedded systems – and for that matter antithetical to realtime.
That doesn’t mean it’s wrong to have the desire to satisfy legitimate
requests for its availability in limited domains (embedded databases,
media streaming, etc.) for performance and/or portability. It doesn’t
mean its a priority item, either.

Any approach would have to be in keeping with the QNX philosophy
regarding demand paging – RTP has demand paging available – in
addition to resolving the issue of applying it to the driver
framework and all the drivers. Demand paging has to be available
to an application without imposing any costs on applications that
don’t use it, or imposing unpredictable latencies on higher
priority processes.

If you did want to use it, you, as an applications programmer
would have to assume responsibility for mitigating the impact
introduced to your own application, however.

That said, I see it being conceptually simple for devices, but serving
very limited practical purposes in that area, when most
devices drivers can support some level of memory-mapped I/O
with just a few lines of code changed.

---

Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.

[Warren_Peece1]

“Steve Furr” <furr@qnx.com> wrote in message news:903j3b$32t$1@nntp.qnx.com…
| In article <903gdk$1qv$1@inn.qnx.com>, Warren Peece <warren@nospam.com>
wrote:
| >
| >“Steve Furr” <furr@qnx.com> wrote in message
news:903c7i$d67$1@nntp.qnx.com…
| >
| >[ eloquent presentation of information deleted ]
| >
| >| I can assure you, QNX developers would love to have a complete
| >| VM system, driver interfaces and drivers in place that allowed
| >| mapping files for any device, [ … ]
| >
| >Speak for yourself, buddy! Even for my projects where I’m patiently
awaiting
| [snip]
|
| Whoa, Peace Warren,

That wasn’t an angry outburst, merely what I thought was an amusing use of a
colloquialism. Sorry if I gave the impression I was upset, because I wasn’t.
But now I am, damnit! (hehehe)

-Warren

[John_B_Stephens_II]

Warren Peece wrote:

“Steve Furr” <> furr@qnx.com> > wrote in message news:903j3b$32t$> 1@nntp.qnx.com> …
| In article <903gdk$1qv$> 1@inn.qnx.com> >, Warren Peece <> warren@nospam.com
wrote:
|
| >“Steve Furr” <> furr@qnx.com> > wrote in message
news:903c7i$d67$> 1@nntp.qnx.com> …
|
| >[ eloquent presentation of information deleted ]
|
| >| I can assure you, QNX developers would love to have a complete
| >| VM system, driver interfaces and drivers in place that allowed
| >| mapping files for any device, [ … ]
|
| >Speak for yourself, buddy! Even for my projects where I’m patiently
awaiting
| [snip]
|
| Whoa, Peace Warren,

That wasn’t an angry outburst, merely what I thought was an amusing use of a
colloquialism. Sorry if I gave the impression I was upset, because I wasn’t.
But now I am, damnit! (hehehe)

-Warren

Bright minds everywhere…yet so many newbies suffer incomplete installations and
malformed impressions. Curse ye gods! Curse your symantic musings! Bring us your
promised reigns or we will suffer newer gods to thunder over us!

[Warren_Peece1]

“John B. Stephens,II” <jbstephe@flash.lakeheadu.ca> wrote in message

| Bright minds everywhere…yet so many newbies suffer incomplete installations
and
| malformed impressions. Curse ye gods! Curse your symantic musings! Bring us
your
| promised reigns or we will suffer newer gods to thunder over us!

Oooo, a drama major!

[John_Doe]

“Warren Peece” <warren@nospam.com> wrote in message
news:903qmk$7uf$1@inn.qnx.com…

“John B. Stephens,II” <> jbstephe@flash.lakeheadu.ca> > wrote in message

| Bright minds everywhere…yet so many newbies suffer incomplete
installations
and
| malformed impressions. Curse ye gods! Curse your symantic musings! Bring
us
your
| promised reigns or we will suffer newer gods to thunder over us!

Oooo, a drama major! >

See what happens when you add multimedia capabilities to an O/S

[Igor_Kovalenko2]

John Doe <john@csical.com> wrote in message news:903r03$891$1@inn.qnx.com…

“Warren Peece” <> warren@nospam.com> > wrote in message
news:903qmk$7uf$> 1@inn.qnx.com> …
“John B. Stephens,II” <> jbstephe@flash.lakeheadu.ca> > wrote in message

| Bright minds everywhere…yet so many newbies suffer incomplete
installations
and
| malformed impressions. Curse ye gods! Curse your symantic musings!
Bring
us
your
| promised reigns or we will suffer newer gods to thunder over us!

Oooo, a drama major! >

See what happens when you add multimedia capabilities to an O/S >

He’s right actually. It appears like developers at QNX are either so damned
smart that it is an insult for them to even care about simple things, or all
simple things are assigned to those who are so damned stupid… Either way
we have to wait endlessly for some rather easy problems to be fixed.

Problems with identifying SCSI drives geometry for example were known for a
year at least and nothing has been done. Why login was broken? Or why diff
is broken now? Has anyone tried to do a recursive diff on 2 source trees to
generate patches?

Ok, that’s off-topic. Returning to subject, I think that ignorance wrt
mmap() is not right thing, even if it’s inappropriate for embedded systems.
Lack of mmap() compatibility makes it harder to port software and lack of
software makes our life harder. In an ideal world we could all be gods and
design our systems in most beatiful ways but in ugly reality there are
deadlines and budgets and using readily available components is necessity.

There are other problems of that sort. For the sake of portability QNX could
have implemented SYSV IPC, at least partially. And it would not hurt to have
STREAMS model for drivers, given that io-net architecture is almost there.
One of our vendors for example decided to port relevant part of STREAMS
framework instead of porting the drivers when we contracted them for
Neutrino support. Other option was to maintain 2 separate driver models and
they did not like it.

So yes, I still want full mmap() and real VM, even though I do care about
realtime. And not only for portability but for many benefits which they can
provide. A system simply can’t scale up very well if it does not implement
those. Indeed, adding multimedia capabilities creates another class of
realtime applications, which need both realtime and some features typically
not associated with RTOSes.

• igor

[Warren_Peece1]

“Igor Kovalenko” <Igor.Kovalenko@motorola.com> wrote in message
news:9042nn$cq5$1@inn.qnx.com…

| He’s right actually. It appears like developers at QNX are either so damned
| smart that it is an insult for them to even care about simple things, or all
| simple things are assigned to those who are so damned stupid… Either way
| we have to wait endlessly for some rather easy problems to be fixed.

Personally I’d chalk it up to deadlines, scheduling and priorities rather than
intelligence on behalf of the QNX staff. But in either case, yes we have to
wait. Unfortunate, but, what’s a guy to do?

| Problems with identifying SCSI drives geometry for example were known for a
| year at least and nothing has been done. Why login was broken? Or why diff
| is broken now? Has anyone tried to do a recursive diff on 2 source trees to
| generate patches?

Easy answer there is “shit happens” (especially when you’re porting stuff).
Again I’m sure they want to fix all of these things, it’s just a question of
what’s more pressing at the moment.

| Ok, that’s off-topic. Returning to subject, I think that ignorance wrt
| mmap() is not right thing, even if it’s inappropriate for embedded systems.
| Lack of mmap() compatibility makes it harder to port software and lack of
| software makes our life harder. In an ideal world we could all be gods and
| design our systems in most beatiful ways but in ugly reality there are
| deadlines and budgets and using readily available components is necessity.

Heh. I don’t think we can get more off-topic than talking about drama

| There are other problems of that sort. For the sake of portability QNX could
| have implemented SYSV IPC, at least partially. And it would not hurt to have
| STREAMS model for drivers, given that io-net architecture is almost there.
| One of our vendors for example decided to port relevant part of STREAMS
| framework instead of porting the drivers when we contracted them for
| Neutrino support. Other option was to maintain 2 separate driver models and
| they did not like it.

I’m not ignoring VM, I’m ignoring scenarios other than what I face as far as
development goes. The only software I write is software that I’m going to use
(for this business). The only software I use (besides QNX supplied packages of
course) is software I write. It’ll be a cold day in hell before I deliberately
write something using SYSV IPC when I have the feature rich QNX IPC to use
instead. I’d rather yank my teeth out with a pliers than interface with any
sort of streams code when I can neatly pass messages to my drivers. Personally
I think that about 85% of the code that other people write just plain sucks and
I’ll write a web server from scratch to do exactly what I want rather than port
a monstrosity like Apache. But that’s just me, I have that luxury because I’m
not in the business of developing software for other people any more (thank God
for that!). VM, memory mapped files, SYSV IPC and Streams are all things that
I’ve used, and stay away from with a vengeance.

| So yes, I still want full mmap() and real VM, even though I do care about
| realtime. And not only for portability but for many benefits which they can
| provide. A system simply can’t scale up very well if it does not implement
| those. Indeed, adding multimedia capabilities creates another class of
| realtime applications, which need both realtime and some features typically
| not associated with RTOSes.
|
| - igor

I do see your point, and having VM on QNX6 won’t bother me a bit- unless it
adds additional overhead to the things I’m going even though I have no use
whatsoever for those additional features. Somebody may even come up with a
very logical scenario where they use such features to their distinct advantage.
However, (this is where I tie back to my original premise about schedules and
whatnot if QNX is delaying the network DDK, the disk DDK, patch A, and all
sorts of other very important stuff in order to put the final touches on their
SYSV IPC library so people can port gigantic, bloated, public domain Un*x
applications to RtP then I think it sucks.

Yeah I know I’m being a selfish bastard, but those are my opinions. I didn’t
mean to imply that in all instances anybody who uses VM is an idiot, I meant to
imply that I think there are better ways to deal with those sorts of issues
that make people resort to VM. Where the VM system may not be applicable to
real-time performance, the custom tailored approach may very well be.
Therefore I personally don’t see it being very important. Also my opinion on
scaleability differs slightly from yours. My theory says that when you’re out
of memory, you’re out of memory and have to devise a clever way of dealing with
on-line and mass storage. Yours says when you’re out of memory, the O.S. will
deal with the mass storage so you don’t have to worry about it. For me, my way
is the only way. In other scenarios, it may not be that important so I can see
where the time saved may make it all worth while.

Again, these are just my jaded opinion that you all begged and begged and
begged me to share with you. That oughta teach you!

-Warren “wayyyyyy out there” Peece

[Rick_Lake1]

Warren Peece wrote:

[lots of useful comments deleted…]

-Warren “wayyyyyy out there” Peece

Why do I get the feeling that it’s Steve Spice talking here
(In a different thread we learn that Warren Peece isn’t your real name.)

[Armin_Steinhoff1]

Steve Furr wrote:

In article <902qfm$b70$> 1@inn.qnx.com> >,
Maurizio Rossi <> mrossi@system-group.it> > wrote:
Please, Mr. Steinhoff and Mr.Berdahl,

can you post the POSIX specs regarding that this stuff MUST (or MUST NOT) be
supported for POSIX
compliancy?

Refer to ISO/IEC 9945-1:1996 (IEEE 1003.1-1996).

It says:

(Section 12.2.1.2)
[ clip … ]

Steve,

thanks for the info … it helps also a lot to
argue for QNX6

Armin

[Armin_Steinhoff1]

Sunil Kittur wrote:

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

Eric Berdahl wrote:

In article <901lri$4dn$> 1@inn.qnx.com> >, “Igor Kovalenko”
Igor.Kovalenko@motorola.com> > wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A23DFD9.FCD56DF3@web_.de…

Hi,

the following sequence of library calls can’t be
used with QNX6

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

The usage of the calls above is fully POSIX and
UNIX98 compliant … but it doesn’t work with
QNX6.

There’s another falacy with the above code. Notice that the thing you’re
mmap’ing is a device (a file descriptor opened from the /dev file
system).

Thus, you also need a driver written to support the mmap system
call.

No … you need just system services and not a
driver.

You do need specific support from the driver.
The core VM system relies on filesystem (or driver)
specific code to control the VM system.

OK … let us not be too picky.

I’m most familiar with SVR4 - on that system mmap
is performed via driver/fs code that decides what
VM segment driver is appropriate, and provides
the necessary interface for the VM system page in
and out. Without that support you don’t get mmap,
and you don’t get unified caching.

eg… what happens if you:

fd = open("/dev/ttyXX")
mmap(…, fd, 0);

Implementing a “unified cache” for a Unix system is
fairly straightforward > > since the file systems,
drivers, VM system and buffer cache are all in the
same address space. With QNX, all of these are in
different address spaces and can be on different
nodes. Other systems with similar architectures,
eg. Chorus have put the VM caching in the kernel.

Interesting … Chorus claims also to be a
distributed RTOS.

This means you need:

1. to re-direct all reads/write to mappable files to
   the local kernel. With the QNX implementation
   you always send the message to the real server.

2. implement a fairly elaborate interface for doing
   page-in/page-out for the VM cache. This affects
   all servers that implement mappable/cacheable files.

3. to handle generally expected coherency for POSIX,
   implement some form of coherency protocol between
   the VM systems on all nodes and the file servers,
   eg. to handle truncation.

This all impacts performance, and increases the
complexity of both the kernel and all servers that
implement cacheable/mappable files.

IMHO it’s better to discuss it now … later could
be too late.
( I refer to the thread support for QNX4 …

Armin

PS: thanks for your detailed posting.

[Warren_Peece1]

“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:3A261D7E.B1515964@SPAM.REDIRECTED.TO.DEV.NULL…

Warren Peece wrote:

[lots of useful comments deleted…]

-Warren “wayyyyyy out there” Peece

Why do I get the feeling that it’s Steve Spice talking here >
(In a different thread we learn that Warren Peece isn’t your real name.)

Is he one of those “Spice Guys”?

[Rick_Lake1]

Warren Peece wrote:

“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 3A261D7E.B1515964@SPAM.REDIRECTED.TO.DEV.NULL> …


Warren Peece wrote:

[lots of useful comments deleted…]

-Warren “wayyyyyy out there” Peece

Why do I get the feeling that it’s Steve Spice talking here >
(In a different thread we learn that Warren Peece isn’t your real name.)

Is he one of those “Spice Guys”?

Steven Spicer was one of the early days QUICS users (like my self). He
was famous for his creative “intra name quotes”.

rick “searching for clues” lake

[Warren_Peece1]

“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:3A275E2F.A7AE2054@SPAM.REDIRECTED.TO.DEV.NULL…

Warren Peece wrote:

“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 3A261D7E.B1515964@SPAM.REDIRECTED.TO.DEV.NULL> …


Warren Peece wrote:

[lots of useful comments deleted…]

-Warren “wayyyyyy out there” Peece

Why do I get the feeling that it’s Steve Spice talking here >
(In a different thread we learn that Warren Peece isn’t your real
name.)

Is he one of those “Spice Guys”?

Steven Spicer was one of the early days QUICS users (like my self). He
was famous for his creative “intra name quotes”.

rick “searching for clues” lake

Yes indeed, I remember Steve “Spicer is nicer” Spicer’s quotes. He was
somewhat more creative than I however. I wish he’d come back and at least
humor us for a while, he was enjoyable to read.

-Warren “I’ve been here too long?” Peece

[Paul_Missman]

Warren Peece <warren@nospam.com> wrote in message
news:90453a$e3u$1@inn.qnx.com…

Yeah I know I’m being a selfish bastard, but those are my opinions. I
didn’t
mean to imply that in all instances anybody who uses VM is an idiot, I
meant to
imply that I think there are better ways to deal with those sorts of
issues
that make people resort to VM. Where the VM system may not be applicable
to
real-time performance, the custom tailored approach may very well be.
Therefore I personally don’t see it being very important. Also my opinion
on
scaleability differs slightly from yours. My theory says that when you’re
out
of memory, you’re out of memory and have to devise a clever way of dealing
with
on-line and mass storage. Yours says when you’re out of memory, the O.S.
will
deal with the mass storage so you don’t have to worry about it. For me,
my way
is the only way. In other scenarios, it may not be that important so I
can see
where the time saved may make it all worth while.

I guess the problem here is that none of us realtime programmers went to the
POSIX standards meetings to say that standards should not be written in a
way which implies the existance of a particular memory model, architecture,
etc… If the standard implies adherence to a shared VM model, then it is a
bad standard. Hard realtime code can’t be written in the presence of such a
model, because VM throws fine grained execution determination right out the
window. If you need a millionth of a second response time, and the system
decides right then to do a page out, your application is non-functional.
QNX shouldn’t be required to fake a shared VM model to satisfy POSIX. They
should go back to the standards committee, and suggest that the requirement
is poorly formed. (If it is, in fact, an actual requirement.)

The fact that there are some realtime operating systems which have a shared
VM model shouldn’t require QNX to implement same. In those OSes, there are
usually explicit programmer notes on the avoidance of paging for
close-tolerance realtime operations.

Personally, I don’t mind using a realtime OS with paging if paging can be
circumvented. However, I don’t think all realtime OSes should be required
to implement such a model.

Paul “former realtime guy” Missman