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

bridged with qdn.public.qnxrtp.os
Post Reply
Sebastien Marineau

Re: Maximum addressing range: PCI

Post by Sebastien Marineau » Thu Apr 19, 2001 8:13 pm

Wayne Fisher <wayne.fisher@focusautomation.com> wrote:
: "Brian Stecher" <bstecher@qnx.com> wrote in message
: news:9bk0mt$sk9$1@nntp.qnx.com...
:> Wayne Fisher <wayne.fisher@focusautomation.com> wrote:
:> > But, if QNX6 uses 64bits behind the MMU than it's theoretically possible
:> > that a full 32 bits of addressing could be allocated to PCI devices
:> > (assuming, of course, that the CPU itself can address more than 4GB).
:> > However, with processes limitted to 4GB of address, no one process could
:> > address all 32bits worth of the PCI bus.
:>
:> The current implementation only supports 32 bits of physical address. This
:> will be increased in the future, but there's no time frame for it yet.

: Ok, I think that I'm getting the picture. It goes something like this:

: 4096 MB Max. physical address range.
: -512 MB Reserved for OS (for at least some of the supported
: processors)
: -M MB Size of physical memory.
: ---------
: P MB Space left for PCI.

Hi Wayne,

here's a (hopefully) more detailed answer to your question, with some
specifics on PowerPC.

First, the virtual address space of a given process is (of course) 4GB,
of which the bottom 1GB is taken up by the kernel and related supervisor
mappings. So 3GB is available for *each* process.

On the hardware side, the PowerPC has a 32 bit physical address bus (except
the 7450, which has 36 bits). So the processor itself can address up
to 4GB of physical memory. Virtual "process" addresses (pointers) in the
TLB and in the MMU get translated to 32 bits of physical addresses.

Now, where things get a little more complicated is when you put a bridge
in the system. The bridge does CPU<-->PCI translation, and normally the
PowerPC bridges have fixed-size windows (in the 32 bit physical world) of
where memory, PCI memory, PCI I/O, ROM etc. go. As an example, the MPC107
bridge (probably what you're using) has

0-1G for RAM
1-2G reserverd
2G-~3.5G PCI Memory
and then further windows for PCI I/O, ROM etc.

So the limit on PCI memory in that case is 1.5GB total,
quite a bit less than what the processor can address. Further, the memory
map can usually not be modified (this is a CHRP memory map, BTW). Mapping
512MB in multiple processes or 1.5GB in a given process would certainly be
possible, and would not hit any limits except the RAM needed for MMU
structures.

I hope that answers the question... as an aside, inside the kernel, we keep
track of physical addresses using 64 bit variables. This allows us to
address more than 4GB physical on processors that support this (MIPS R4000,
most notably). Some day, it may also be supported on some other processors.

Sebastien

_______________________
Sebastien Marineau
Netcom Architect
QNX Software Systems Ltd
(613) 271-9336

sebastien@qnx.com

Igor Kovalenko

Re: Maximum addressing range: PCI

Post by Igor Kovalenko » Fri Apr 20, 2001 6:17 am

"Sebastien Marineau" <sebastien@qnx.com> wrote in message
news:9bngsg$f9k$1@nntp.qnx.com...
Hi Wayne,

here's a (hopefully) more detailed answer to your question, with some
specifics on PowerPC.
Must have been real kaboom to get Seb talking here these days, instead of
enjoying his roadster ;)
Still too cold up in Ottawa I guess ...
First, the virtual address space of a given process is (of course) 4GB,
of which the bottom 1GB is taken up by the kernel and related supervisor
mappings.
Now I see why IP values for procnto idle thread are so different on PPC and
x86 ;)
They are just around 1G on PPC...
So 3GB is available for *each* process.

On the hardware side, the PowerPC has a 32 bit physical address bus
(except
the 7450, which has 36 bits). So the processor itself can address up
to 4GB of physical memory. Virtual "process" addresses (pointers) in the
TLB and in the MMU get translated to 32 bits of physical addresses.

Now, where things get a little more complicated is when you put a bridge
in the system. The bridge does CPU<-->PCI translation, and normally the
PowerPC bridges have fixed-size windows (in the 32 bit physical world) of
where memory, PCI memory, PCI I/O, ROM etc. go. As an example, the MPC107
bridge (probably what you're using) has

0-1G for RAM
1-2G reserverd
2G-~3.5G PCI Memory
and then further windows for PCI I/O, ROM etc.
The CHRP memory map I found in Motorola docs is somewhat different.
0-dram_size for RAM
2G-3.8125G for PCI memory
3.8125 - 4G for all the rest.

It also says that the map can be changed (partucularly PCI memory size) by
programming PCI ASIC registers, at least with Hawk and Raven ASICs. Maximum
possible PCI window size is said to be 4Gb - dram_size. Practical limit
would be less since nobody usually wants to mess up much with upper 0.1875G,
but it sounds like 3Gb for PCI should be possible.

BTW, on MCP7xx boards CHRP is not even default map style after boot, PREP
style is default. Not sure about MPC107 and not sure what NTO does with it
when it starts...
So the limit on PCI memory in that case is 1.5GB total,
quite a bit less than what the processor can address. Further, the memory
map can usually not be modified (this is a CHRP memory map, BTW). Mapping
512MB in multiple processes or 1.5GB in a given process would certainly be
possible, and would not hit any limits except the RAM needed for MMU
structures.

I hope that answers the question... as an aside, inside the kernel, we
keep
track of physical addresses using 64 bit variables. This allows us to
address more than 4GB physical on processors that support this (MIPS
R4000,
most notably). Some day, it may also be supported on some other
processors.
You aren't talking about IA64, are you? :)

Thanks for explanations,
- Igor

Wayne Fisher

Re: Maximum addressing range: PCI

Post by Wayne Fisher » Fri Apr 20, 2001 7:54 pm

Most of the defect detection actually occurs in those large FPGAs. Today's
microprocessors are fast but they can't do much when you throw 600 million
pixels per second at them. So we use hardware to do the pixel rate stuff and
leave the software to collect and filter what the hardware finds.

I wouldn't really call it AI since the rules for what should be considered a
defect are known and algorithmic in nature.

Wayne

"Bill Caroselli" <Bill@Sattel.com> wrote in message
news:9bnelf$9fp$1@inn.qnx.com...
Cool. So AI type software 'looks' at the images for defects?

--
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



"Wayne Fisher" <wayne.fisher@focusautomation.com> wrote in message
news:9bnctl$8g4$1@inn.qnx.com...

A fully configured system will have up to 11 of these boards spread
across
6
single board computers. Basically we need to process a LOT of image data
and
distill it down to a simple list of where defects in the product occur
and
what type of defect it is.


Wayne Fisher

Re: Maximum addressing range: PCI

Post by Wayne Fisher » Fri Apr 20, 2001 7:58 pm

Thanks Sebastien. This is a great help and explains everything I need to
know.

Looks like we will have to keep our address blocks to less than 256MB if we
want everything to fit in. This won't bother our hardware guys much but it
will probably complicate the lives of my software group.... :(

Thanks again,

Wayne

"Sebastien Marineau" <sebastien@qnx.com> wrote in message
news:9bngsg$f9k$1@nntp.qnx.com...
Hi Wayne,

here's a (hopefully) more detailed answer to your question, with some
specifics on PowerPC.

First, the virtual address space of a given process is (of course) 4GB,
of which the bottom 1GB is taken up by the kernel and related supervisor
mappings. So 3GB is available for *each* process.

On the hardware side, the PowerPC has a 32 bit physical address bus
(except
the 7450, which has 36 bits). So the processor itself can address up
to 4GB of physical memory. Virtual "process" addresses (pointers) in the
TLB and in the MMU get translated to 32 bits of physical addresses.

Now, where things get a little more complicated is when you put a bridge
in the system. The bridge does CPU<-->PCI translation, and normally the
PowerPC bridges have fixed-size windows (in the 32 bit physical world) of
where memory, PCI memory, PCI I/O, ROM etc. go. As an example, the MPC107
bridge (probably what you're using) has

0-1G for RAM
1-2G reserverd
2G-~3.5G PCI Memory
and then further windows for PCI I/O, ROM etc.

So the limit on PCI memory in that case is 1.5GB total,
quite a bit less than what the processor can address. Further, the memory
map can usually not be modified (this is a CHRP memory map, BTW). Mapping
512MB in multiple processes or 1.5GB in a given process would certainly be
possible, and would not hit any limits except the RAM needed for MMU
structures.

I hope that answers the question... as an aside, inside the kernel, we
keep
track of physical addresses using 64 bit variables. This allows us to
address more than 4GB physical on processors that support this (MIPS
R4000,
most notably). Some day, it may also be supported on some other
processors.

Sebastien

Brian Northgrave

Re: QNX RTP Patch C & Language Supplement Betas Now Availab

Post by Brian Northgrave » Thu May 24, 2001 4:02 pm

QNX RTP Patch C & Language Supplement Patch B (Beta Release Candidate)
now available for download!!!!

Patch C is now available as a beta download from:

http://betas.qnx.com/beta

Just point your package installer at the url.

This distribution must be installed over a Patch B system.


Release Notes for this distribution:

_________________________________________________________________

QNX RTP - Patch C (Based on QNX RTOS v6.0.0 Patch C)


Fixes & errata

_________________________________________________________________

Note: If you have an earlier release of QNX RTP, you should recompile
ALL your existing QNX RTP code with this distribution.
_________________________________________________________________

This section covers the following:

* New input (devi-*) drivers
* Photon Library
* phs-to-ps
* PtOSContainer
* PxLoadImage()
* Render Library

New input (devi-*) drivers

* Improved touchscreen support.

Photon Library

* Fixed crash problem re: PtFileSelection.
* Fixed unknown symbol replacement in translation lib routines.
* Fixed buffer overflow problem in translation routines -- the
helpviewer can now display Japanese help pages correctly.

phs-to-ps

* Fixed segment violation problem when processing draw streams with
large images.
* Added enhancements/improvements to the output of phs-to-ps and
phs-to-escp2.
* Fixed the behavior of offscreen contexts when used within a
widget's draw function (Pt_ARG_RAW_DRAW_F() of PtRaw widget).

PtOSContainer

* Fixed problems with translation, blit, and render operations.
* Added support for rendering images and rep-images (repeating
images) with transparency into offscreen contexts or memory
contexts that didn't work correctly.

PxLoadImage()

* Fixed segment violation problem when loading GIFs with a
transparent color.

Render Library

* Improved support for rendering and printing wide chars (UTF-16).
* Updated to better support image rendering, translations, polygons,
etc.




_________________________________________________________________

QNX RTP - Language Supplements (2.0 Patch B)


Fixes & errata

_________________________________________________________________


vpim (Japanese Input Method)

* Added new options:

-F font
Specify default font.

-@ x,y
Specify the default position for the input window.
____________________________________________________

Note: The -F and -@ options are applied when no FEP
(Front End Processor) rectangle is defined.
____________________________________________________

* Fixed the input window size.

cpim (Chinese Input method)

* ESC will cancel current input sequence.
* Fixed a bug caused by changing the default font with the selection
list.
* Selection list is always on the screen.
_________________________________________________________________


Happy beta testing!!!

thanx
ben
QA
QSS

Dean Douthat

Re: QNX RTP Patch C & Language Supplement Betas Now Availab

Post by Dean Douthat » Thu May 24, 2001 8:45 pm

If none of the fixes/enhancements in Patch C are of interest, can I skip it?
What I'm asking is when subsequent patches/releases come out, will they
presuppose I have installed patch C or will they pick up from my current
installation (patch B)?

Brian Northgrave wrote:
QNX RTP Patch C & Language Supplement Patch B (Beta Release Candidate)
now available for download!!!!

Patch C is now available as a beta download from:

http://betas.qnx.com/beta

Just point your package installer at the url.

This distribution must be installed over a Patch B system.

Release Notes for this distribution:

_________________________________________________________________

QNX RTP - Patch C (Based on QNX RTOS v6.0.0 Patch C)


Fixes & errata

_________________________________________________________________

Note: If you have an earlier release of QNX RTP, you should recompile
ALL your existing QNX RTP code with this distribution.
_________________________________________________________________

This section covers the following:

* New input (devi-*) drivers
* Photon Library
* phs-to-ps
* PtOSContainer
* PxLoadImage()
* Render Library

New input (devi-*) drivers

* Improved touchscreen support.

Photon Library

* Fixed crash problem re: PtFileSelection.
* Fixed unknown symbol replacement in translation lib routines.
* Fixed buffer overflow problem in translation routines -- the
helpviewer can now display Japanese help pages correctly.

phs-to-ps

* Fixed segment violation problem when processing draw streams with
large images.
* Added enhancements/improvements to the output of phs-to-ps and
phs-to-escp2.
* Fixed the behavior of offscreen contexts when used within a
widget's draw function (Pt_ARG_RAW_DRAW_F() of PtRaw widget).

PtOSContainer

* Fixed problems with translation, blit, and render operations.
* Added support for rendering images and rep-images (repeating
images) with transparency into offscreen contexts or memory
contexts that didn't work correctly.

PxLoadImage()

* Fixed segment violation problem when loading GIFs with a
transparent color.

Render Library

* Improved support for rendering and printing wide chars (UTF-16).
* Updated to better support image rendering, translations, polygons,
etc.

_________________________________________________________________

QNX RTP - Language Supplements (2.0 Patch B)


Fixes & errata

_________________________________________________________________

vpim (Japanese Input Method)

* Added new options:

-F font
Specify default font.

-@ x,y
Specify the default position for the input window.
____________________________________________________

Note: The -F and -@ options are applied when no FEP
(Front End Processor) rectangle is defined.
____________________________________________________

* Fixed the input window size.

cpim (Chinese Input method)

* ESC will cancel current input sequence.
* Fixed a bug caused by changing the default font with the selection
list.
* Selection list is always on the screen.
_________________________________________________________________

Happy beta testing!!!

thanx
ben
QA
QSS

Brian Northgrave

Re: QNX RTP Patch C & Language Supplement Betas Now Availab

Post by Brian Northgrave » Fri May 25, 2001 3:55 pm

Dean Douthat <ddouthat@faac.com> wrote:
If none of the fixes/enhancements in Patch C are of interest, can I skip it?
What I'm asking is when subsequent patches/releases come out, will they
presuppose I have installed patch C or will they pick up from my current
installation (patch B)?
Don't worry too much, I think you'll be alright if you want to skip it.
If they are any issues with future upgrades they will be taken care of
at the time.

thanx

ben


Brian Northgrave wrote:

QNX RTP Patch C & Language Supplement Patch B (Beta Release Candidate)
now available for download!!!!

Patch C is now available as a beta download from:

http://betas.qnx.com/beta

Just point your package installer at the url.

This distribution must be installed over a Patch B system.

Release Notes for this distribution:

_________________________________________________________________

QNX RTP - Patch C (Based on QNX RTOS v6.0.0 Patch C)


Fixes & errata

_________________________________________________________________

Note: If you have an earlier release of QNX RTP, you should recompile
ALL your existing QNX RTP code with this distribution.
_________________________________________________________________

This section covers the following:

* New input (devi-*) drivers
* Photon Library
* phs-to-ps
* PtOSContainer
* PxLoadImage()
* Render Library

New input (devi-*) drivers

* Improved touchscreen support.

Photon Library

* Fixed crash problem re: PtFileSelection.
* Fixed unknown symbol replacement in translation lib routines.
* Fixed buffer overflow problem in translation routines -- the
helpviewer can now display Japanese help pages correctly.

phs-to-ps

* Fixed segment violation problem when processing draw streams with
large images.
* Added enhancements/improvements to the output of phs-to-ps and
phs-to-escp2.
* Fixed the behavior of offscreen contexts when used within a
widget's draw function (Pt_ARG_RAW_DRAW_F() of PtRaw widget).

PtOSContainer

* Fixed problems with translation, blit, and render operations.
* Added support for rendering images and rep-images (repeating
images) with transparency into offscreen contexts or memory
contexts that didn't work correctly.

PxLoadImage()

* Fixed segment violation problem when loading GIFs with a
transparent color.

Render Library

* Improved support for rendering and printing wide chars (UTF-16).
* Updated to better support image rendering, translations, polygons,
etc.

_________________________________________________________________

QNX RTP - Language Supplements (2.0 Patch B)


Fixes & errata

_________________________________________________________________

vpim (Japanese Input Method)

* Added new options:

-F font
Specify default font.

-@ x,y
Specify the default position for the input window.
____________________________________________________

Note: The -F and -@ options are applied when no FEP
(Front End Processor) rectangle is defined.
____________________________________________________

* Fixed the input window size.

cpim (Chinese Input method)

* ESC will cancel current input sequence.
* Fixed a bug caused by changing the default font with the selection
list.
* Selection list is always on the screen.
_________________________________________________________________

Happy beta testing!!!

thanx
ben
QA
QSS

Alex Cellarius

Re: What's the equivalent of tinit?

Post by Alex Cellarius » Tue Jun 12, 2001 8:08 am

Thanks Igor
(Perhaps the the on-line docs should mention this? All the examples there have everything in the boot image).

On Mon, 11 Jun 2001 16:51:38 -0500, Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
It is called 'init', just like in Unix. In fact earlier versions even
used 'getty' instead of QNX-ish 'tinit' for terminal initialisation.

What I do is run my own pre-init shell script from boot image, which
takes care about our custom stuff first, then starts 'init' takes care
about getty/login stuff. I use SYSV-like convention for custom scripts
(i.e., everything in directory X what has execute permission gets
executed in the alphabetical order). That way you can plug things in and
out without editing any existing files and that saves LOT of trouble.
Customers tend to screw startup scripts miserably using vi in hyperterm
and if everything is in one script the system gets unbootable right away
;)

Brian Northgrave

Re: 6.1.0 PatchA Now Availabel & Online!!

Post by Brian Northgrave » Mon Oct 01, 2001 8:37 pm

6.1.0 PatchA Now Available & Online !!!!
----------------------------------------

Patch A for QNX 6.1.0 is now generally available and installable from
the QNX WWW Repository in the Package Installer.

The Release Notes are also available online at ->

http://qdn.qnx.com/news/releases/releasenotes_A.html

Please read the release Notes if you have any questions.
The problem with Package Installer & Proxy Servers is also
fixed and the documented upgrade path is in the Release Notes.

thanx
ben

Shashank

Re: Keyboard Input

Post by Shashank » Wed Apr 24, 2002 3:15 pm

Hello,
I accept Keyboard events in my application. Basically
i open up a region in the application that accepts Keyboard events. But i
want to accept keyboard events only if the Application is in FRONT of all
the other processes and not otherwise. Is there a way to do this?

Thanks,
Shashank

Shashank

Re: SIGRTMIN & SIGRTMAX

Post by Shashank » Tue Apr 30, 2002 4:50 pm

Hi,
These signals are not declared in signal.h . Can someone
tell me where the 16 User defined signals are declared?

Thanks,
Shashank

David Gibbs

Re: SIGRTMIN & SIGRTMAX

Post by David Gibbs » Tue Apr 30, 2002 7:28 pm

Shashank <sbalijepalli@precitech.com> wrote:
Hi,
These signals are not declared in signal.h . Can someone
tell me where the 16 User defined signals are declared?
Hm... this conference is for QNX Neutrino 6, you didn't
state what operating system you are using, so I assumed
QNX6. They have been in signal.h since the days of (at least)
Neutrino 2.0.

If you're using QNX4, you only have the 2 user defined
signals (SIGUSR1, SIGUSR2). The Posix spec that extended
the number of signals wasn't around when QNX4 was designed.

For QNX4 questions, you're better to post them in
qdn.public.qnx4

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Leandro Colen

Re: IRQ 0 - Interrupt Handling

Post by Leandro Colen » Wed May 22, 2002 3:00 pm

Hey ed1k,

Why i need this? Well, as i've told before in other post, i'm porting
some
programs from the old DOS that use this feature.

Usualy DOS programs used INT 0x1c or INT 0x08 to take control every 55ms
(handle IRQ 0 or to be in
long train of handlers). But you don't need use it anymore in QNX. You
have much more safe timers.
The timers in QNX are very safe to do this kind of work right? Every
time-interval i need to gather some hardware information and make some
decisions.. i CAN thrust in the timers right? That's what i see until now.
A little thing.. In my program i try to configure the timer to repeat every,
for example, 100ms, my osciloscope shows me that i'm getting an accuracy of
80 ms, when i try to use 1ms is see that this accuracy is 0.8ms.
I've set the thread priority to 63, just for minimize the interferece with
other programs, and do some tests using and QNX build image too (As is
explain in Programmers Guide Manual) and again i get this 20% difference....

What makes this 20% difference?


What i want to do now is to test the InterruptAttach routines. I'm trying to
simulate an Paralel Interrupt to see if my program is working well, but it's
more complicated then just send a 5v signal to the ACK pin of the port.

So, i just want to see if my InterruptAttach code is working, how can i
simulate an Interrupt ?
I've done a lot of sucessful tests using timer (Thanks to Rob again),
and
now i want the timer to generate an interrupt for my tests with
interrupt
routines.

You can use messages and pulses in QNX instead of users' vectors and soft
INT in DOS. Ideology of
DOS and QNX is quite different. You're able to use all your DOS background
but don't copy
everything from one OS to another.
Yes.. That's what i'm trying to do... Porting not just the code from DOS to
QNX, but adapting the code to work better!

Thanx
Leandro

P.S. I'm posting this message in the qdn.public.qnxrtp.os too ... I think
that newsgroup is better to do this kind of questions and discussions. I
will stop posting this in this group (qdn.public.qnxrtp.devtools)

ed1k

Re: IRQ 0 - Interrupt Handling

Post by ed1k » Wed May 22, 2002 4:26 pm

Leandro Colen <lcrocha@yahoo.com> wrote in article <acgbdg$rpd$1@inn.qnx.com>...
Hey ed1k,



Why i need this? Well, as i've told before in other post, i'm porting
some
programs from the old DOS that use this feature.

Usualy DOS programs used INT 0x1c or INT 0x08 to take control every 55ms
(handle IRQ 0 or to be in
long train of handlers). But you don't need use it anymore in QNX. You
have much more safe timers.

The timers in QNX are very safe to do this kind of work right? Every
time-interval i need to gather some hardware information and make some
decisions.. i CAN thrust in the timers right?
Yes, you can trust to the timer ;-) Be warned though, the timer should give you the time not less
than you want, thus you get biggest time interval. There is good article at qdn.qnx.com "Concept of
Time" or something.
In QNXRTP 6.1A the better time resolution is 0.5 milisecond, but by default it's setted to 1.0
millisecond. See ClockPeriod().
That's what i see until now.
A little thing.. In my program i try to configure the timer to repeat every,
for example, 100ms, my osciloscope shows me that i'm getting an accuracy of
80 ms, when i try to use 1ms is see that this accuracy is 0.8ms.
I've set the thread priority to 63, just for minimize the interferece with
other programs, and do some tests using and QNX build image too (As is
explain in Programmers Guide Manual) and again i get this 20% difference....
Very odd. Did you try the another osciloscope?

--
Eduard.
ed1k at ukr dot net


What makes this 20% difference?


What i want to do now is to test the InterruptAttach routines. I'm trying to
simulate an Paralel Interrupt to see if my program is working well, but it's
more complicated then just send a 5v signal to the ACK pin of the port.

So, i just want to see if my InterruptAttach code is working, how can i
simulate an Interrupt ?

I've done a lot of sucessful tests using timer (Thanks to Rob again),
and
now i want the timer to generate an interrupt for my tests with
interrupt
routines.

You can use messages and pulses in QNX instead of users' vectors and soft
INT in DOS. Ideology of
DOS and QNX is quite different. You're able to use all your DOS background
but don't copy
everything from one OS to another.

Yes.. That's what i'm trying to do... Porting not just the code from DOS to
QNX, but adapting the code to work better!

Thanx
Leandro

P.S. I'm posting this message in the qdn.public.qnxrtp.os too ... I think
that newsgroup is better to do this kind of questions and discussions. I
will stop posting this in this group (qdn.public.qnxrtp.devtools)






Chris McKillop

Re: Thead Priority

Post by Chris McKillop » Mon May 27, 2002 9:09 am

[Moving this to .os]
Plus, this method relies totally on the fact that the name has appeared in
/net. In my experience the ndp is not 100% reliable in this respect and it
doesn't work at all over QNet+TCP/IP+PPP+serial link. I terms of QNX4 vs
QNX6 gripes, setting up QNX4 networking to run over a serial link is a walk
in the park. OTOH QNet over a serial link is a tar pit for a beginner (and
it isn't documented properly, if at all).
You can try using devn-fd.so to make a direct connection. I have not tried
this recently but I will be doing so very shortly (for the qPaq project).
OK, so if we are to abandon the QNX4 concept of name location, then what
is/are the recommended method(s) whereby processes can make contact over a
networked system? So we are urged to use a resource manager, but how? Should
we write a QNX6 version of nameloc?
I think the idea is to find the processes by always using /net. In the
local case you can use "/net/localhost/" and if you need to talk to a remote
machine you can use "/net/machinename". This doesn't cover global names
but the reality is you generally know the name of the machine you want to
talk to anyways. At least this is true in a semi-fixed system. Lots of
cases where this isn't true though, I will admit. And, to head off
people, if you open "/net/localhost/dev/ser1" qnet will only be involved
in the open() - once you have the fd it will all be local.

One of the issues that I personally didn't like about how naming worked on
QNX4 was the fact that you where basically forced to use the global name
space to communicate between two nodes and when there where mulitple
registrations of the same global name sometimes things worked out kinda funny.
You could use the nd param to qnx_name_lookup() but even the docs told you
not to do so. ;) So I think you will find when global naming does come to
QNX6 it will be alot more complex of a system so you will be able to handle
the case of multiple machines with the same named resource. Perhaps using
an open standard like LDAP or some other open scheme.

<kinda off topic>

Another thing I found light-years ahead of QNX4 was the push to use resmgrs
so that all applications can use the POSIX APIs to communicate to the
managers over the network. Using a global name is pretty much useless if
you want to use perl to talk to your service. Also, the //#/ stuff was
really painful for non-QNX applications since the rules for path space
expansion takes //#/ and turns it into /#/, which isn't what you want at all.
This was a pain with bash and emacs and anything else that did any sort of
internal path-name expansion.

</kinda off topic>

So I am not so sure if the baby was tossed with the bathwater or if the baby
just grew up and a new baby came along.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Post Reply

Return to “qdn.public.qnxrtp.os”