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

message unavailable

[brought back to qdn.public.qnxrtp.os from private mail]

On 3 Oct, Xiaodan Tang wrote:

Previously, Thomas Hentschel wrote in qdn.public.qnxrtp.os:
Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
Steve Tomkins wrote:

gmman@qnx.com > wrote:
: How do I change to big stack implimentation? Thanks in advance.

[snip]

set(IONET_CMD, io-net -ptcpip -ppppmgr)
and reboot.

Well, I tried this with /etc/system/enum/include/net and
/pkgs/base/qnx/os/drivers2.1/etc/system/enum/include/net (after mounting
/pkgs rw).

No joy, it still starts the tiny stack.

Whats the “Right Way ™” of starting RTP with the full stack ?

[snip

$ cat /etc/system/enum/include/net

macro definitions for network

all
set(IONET_CMD, io-net -ptcpip -ppppmgr)

$ ps -a | grep io-net
61454 61454 1 io-net -pttcpip -ppppmgr

Seems fine for me. Don’t know where it pick up that “ttcpip” > :frowning:

Well, should we file a bug report ?

Well, IMHO, which stack to use could be an option in the Networg Cfg.
Applet.

If I use /etc/rc.d/rc.local, is it still going to use /etc/net.cfg ?

No, the file is created by phlip, and used by netmanager. As long as you
don’t run netmanager, it’s OK.

That takes a bit chunk out of the user friendliness of RTP if everyone
had to edit rc.local for his network setup.

As for “Right Way”, I really don’t know. It’s a desition of
“enum” guys.

Would be nice for one of the “enum” guys to speak up > :slight_smile:

:slight_smile:

-xtang

/me looks for the “enum guys”

-Th

Thomas Hentschel <thomas@hentschel.net> wrote:

[brought back to qdn.public.qnxrtp.os from private mail]

On 3 Oct, Xiaodan Tang wrote:
Previously, Thomas Hentschel wrote in qdn.public.qnxrtp.os:
Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
Steve Tomkins wrote:

gmman@qnx.com > wrote:
: How do I change to big stack implimentation? Thanks in advance.


[snip]

set(IONET_CMD, io-net -ptcpip -ppppmgr)
and reboot.

Well, I tried this with /etc/system/enum/include/net and
/pkgs/base/qnx/os/drivers2.1/etc/system/enum/include/net (after mounting
/pkgs rw).

No joy, it still starts the tiny stack.

Whats the “Right Way ™” of starting RTP with the full stack ?


[snip

$ cat /etc/system/enum/include/net

macro definitions for network

all
set(IONET_CMD, io-net -ptcpip -ppppmgr)

$ ps -a | grep io-net
61454 61454 1 io-net -pttcpip -ppppmgr

Seems fine for me. Don’t know where it pick up that “ttcpip” > :frowning:


Well, should we file a bug report ?

Sigh! Pete showed me a “not working” sample, and now we know
what happened.

If you have a “net~” or “net.bak” in the directory, that one
will also be picked up by enumrater, if fact, any file under
/etc/system/enum/include/ will be picked up.

So just remove those backup file, you should be OK.

Of cause it works for me cause I’m using vi which don’t generated
any backup file.

-xtang

Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
[brought back to qdn.public.qnxrtp.os from private mail]

On 3 Oct, Xiaodan Tang wrote:
Previously, Thomas Hentschel wrote in qdn.public.qnxrtp.os:
Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
Steve Tomkins wrote:

gmman@qnx.com > wrote:
: How do I change to big stack implimentation? Thanks in advance.


[snip]

set(IONET_CMD, io-net -ptcpip -ppppmgr)
and reboot.

Well, I tried this with /etc/system/enum/include/net and
/pkgs/base/qnx/os/drivers2.1/etc/system/enum/include/net (after mounting
/pkgs rw).

No joy, it still starts the tiny stack.

Whats the “Right Way ™” of starting RTP with the full stack ?


[snip

$ cat /etc/system/enum/include/net

macro definitions for network

all
set(IONET_CMD, io-net -ptcpip -ppppmgr)

$ ps -a | grep io-net
61454 61454 1 io-net -pttcpip -ppppmgr

Seems fine for me. Don’t know where it pick up that “ttcpip” > :frowning:


Well, should we file a bug report ?

Sigh! Pete showed me a “not working” sample, and now we know
what happened.

If you have a “net~” or “net.bak” in the directory, that one
will also be picked up by enumrater, if fact, any file under
/etc/system/enum/include/ will be picked up.

So just remove those backup file, you should be OK.

Of cause it works for me cause I’m using vi which don’t generated
any backup file.

-xtang

That surely enough did it. I even created the backup files myself for
easy switching :frowning: . Thanks for the help here !

BTW, that could be a candidate for documentation…

-Th

Thomas Hentschel wrote:

Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
[brought back to qdn.public.qnxrtp.os from private mail]

On 3 Oct, Xiaodan Tang wrote:
Previously, Thomas Hentschel wrote in qdn.public.qnxrtp.os:
Xiaodan Tang wrote:

Thomas Hentschel <> thomas@hentschel.net> > wrote:
Steve Tomkins wrote:

gmman@qnx.com > wrote:
: How do I change to big stack implimentation? Thanks in advance.


[snip]

set(IONET_CMD, io-net -ptcpip -ppppmgr)
and reboot.

Well, I tried this with /etc/system/enum/include/net and
/pkgs/base/qnx/os/drivers2.1/etc/system/enum/include/net (after mounting
/pkgs rw).

No joy, it still starts the tiny stack.

Whats the “Right Way ™” of starting RTP with the full stack ?


[snip

$ cat /etc/system/enum/include/net

macro definitions for network

all
set(IONET_CMD, io-net -ptcpip -ppppmgr)

$ ps -a | grep io-net
61454 61454 1 io-net -pttcpip -ppppmgr

Seems fine for me. Don’t know where it pick up that “ttcpip” > :frowning:


Well, should we file a bug report ?

Sigh! Pete showed me a “not working” sample, and now we know
what happened.

If you have a “net~” or “net.bak” in the directory, that one
will also be picked up by enumrater, if fact, any file under
/etc/system/enum/include/ will be picked up.

So just remove those backup file, you should be OK.

Of cause it works for me cause I’m using vi which don’t generated
any backup file.

-xtang

That surely enough did it. I even created the backup files myself for
easy switching > :frowning: > . Thanks for the help here !

BTW, that could be a candidate for documentation…

Actually it would be nicer if enumerator did not pickup garbage. They
could use execute permissions or give all their files some name
convention.

  • igor

Thomas Hentschel <thomas@hentschel.net> wrote:

BTW, that could be a candidate for documentation…

Actually, it is documented under enum-devices, along with the
enumeration file formats

Previously, Michael J. Ferrador wrote in qdn.public.qnxrtp.newuser, qdn.public.qnxrtp.os:

Informational only - QNXrtp still runs fine

When I do NOT reboot from Win 98 SE (cold boot, reboot from Linux) I get:

range check failed (io) - dev c621 - vend 1045 - class 1018a - addr
80000000 - size 10
alloc failed 80000001 - size 10

PCI -vv (attached file QNXrtpPCI.txt) reports this as my OPTi 82C621 PCI IDE
Controller

Thanks for the information. Yes, we just display this message in case there
is a problem, but seeing yours is working, don’t worry!


I also get this warning about my Voodoo2 (twice - SLI):

range check failed (mem) - dev 2 -vend 121a - class 40000 - addr
ff000000 - size 1000000

But I’m not surprised that w/o a driver, It is confused over
the shared texture memory in an SLI config.



begin 666 QNXrtpPCI.txt
M"E!#22!V97)S:6]N(" @(#T@,BXQ, H0VQA<W,@(" @(" @(" @/2!"<FED
M9V4@
$AO<W0O4$-)0I696YD;W(@240@(" @(" ](#$P-#5H+"!/4%1I($EN
M8RX@“D1E=FEC92!)1” @(" @(#T@8S4U-V@L(#@R0S4U-R!#4%4@0G)I9&=E
M("A6:7!E<BD
4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ]
M(# V,# P,&@*4F5V:7-I;VX@240@(" @/2 Q,6@0G5S(&YU;6)E<B @(" @
M/2 P"D1E=FEC92!N=6UB97(@(#T@, I&=6YC=&EO;B!N=6T@(" ](# 4W1A
M=‘5S(%)E9R @(" @/2 R.#!H"D-O;6UA;F0@4F5G(" @(#T@-V@2&5A9&5R
M('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX
0DE35" @(" @(" @(" @
M/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O<G1E9 I,871E;F-Y
M(%1I;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@“DUA>”!,870@(" @
M(" @(#T@,&YS"DUI;B!’;G0@(" @(" @(#T@,&YS"E!#22!);G0@4&EN(" @
M(#T@3D,26YT97)R=7!T(&QI;F4@/2 P"@I#;&%S<R @(" @(" @(" ]($)R
M:61G92 H4$-)+TE302D
5F5N9&]R($E$(" @(" @/2 Q,#0U:“P@3U!4:2!)
M;F,N( I$979I8V4@240@(” @(" ](&,U-3AH+" X,D,U-3@@25-!($)R:61G
M92!W+U!N4 I00TD@:6YD97@@(" @(" ](#!H"D-L87-S($-O9&5S(" @(#T@
M,#8P,3 P: I2979I<VEO;B!)1" @(" ](#$Q: I"=7,@;G5M8F5R(" @(" ]
M(# 1&5V:6-E(&YU;6)E<B @/2 Q"D9U;F-T:6]N(&YU;2 @(#T@, I3=&%T
M=7,@4F5G(" @(" ](#@R,#!H"D-O;6UA;F0@4F5G(" @(#T@-V@2&5A9&5R
M('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX
0DE35" @(" @(" @(" @
M/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O<G1E9 I,871E;F-Y
M(%1I;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@“DUA>”!,870@(" @
M(" @(#T@,&YS"DUI;B!’;G0@(" @(" @(#T@,&YS"E!#22!);G0@4&EN(" @
M(#T@3D,26YT97)R=7!T(&QI;F4@/2 P"@I#;&%S<R @(" @(" @(" ]($1I
M<W!L87D@
%9’02D
5F5N9&]R($E$(" @(" @/2 Q,#(S:“P@5’)I9&5N=”!-
M:6-R;W-Y<W1E;7,@“D1E=FEC92!)1” @(" @(#T@.38V,&@L(#DS.#4@0WEB
M97(@.3,X-2!0;W)T86)L92!00R!6:61E;R!#;VYT<F]L;&5R("@Y-C8P/RD

M4$-)(&EN9&5X(" @(" @/2 P: I#;&%S<R!#;V1E<R @(" ](# S,# P,&@

M4F5V:7-I;VX@240@(" @/2!D,V@0G5S(&YU;6)E<B @(" @/2 P"D1E=FEC
M92!N=6UB97(@(#T@,@I&=6YC=&EO;B!N=6T@(" ](# 4W1A=‘5S(%)E9R @
M(" @/2 R,#!H"D-O;6UA;F0@4F5G(" @(#T@,V@2&5A9&5R('1Y<&4@(" @
M/2 P:"!3:6YG;&4M9G5N8W1I;VX
0DE35" @(" @(" @(" @/2 P:"!"=6EL
M9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O<G1E9 I,871E;F-Y(%1I;65R(" ]
M(#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@“DUE;2!!9&1R97-S(” @(#T@-# P
M,# P,#!H(#,R8FET(&QE;F=T:" T,3DT,S T(&5N86)L960
365M($%D9’)E
M<W,@(" @/2!F9F5E,# P,&@@,S)B:70@;&5N9W1H(#8U-3,V(&5N86)L960

M36%X($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @(" @/2 P;G,*4$-)
M($EN="!0:6X@(" @/2!)3E0@00I);G1E<G)U<‘0@;&EN92 ](# *“D-L87-S
M(” @(" @(" @(#T@0G)I9&=E(“A00TDO4$-)*0I696YD;W(@240@(” @(" ]
M(#$P,3%H+"!$:6=I=&%L($5Q=6EP;65N="!#;W)P;W)A=&EO;B *1&5V:6-E
M($E$(" @(" @/2 R,F@L(#(Q,34P(%!#22U00TD@0G)I9&=E"E!#22!I;F1E
M>" @(" @(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P-C T,#!H"E)E=FES:6]N
M($E$(" @(#T@,V@*0G5S(&YU;6)E<B @(" @/2 P"D1E=FEC92!N=6UB97(@
M(#T@,3$1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!296<@(" @(#T@,F$P
M: I#;VUM86YD(%)E9R @(" ](#!H"DAE861E<B!T>7!E(" @(#T@,6@@4VEN
M9VQE+69U;F-T:6]N"D))4U0@(" @(" @(" @(#T@,&@@0G5I;&0M:6XM<V5L
M9BUT97-T(&YO="!S=7!P;W)T960
3&%T96YC>2!4:6UE<B @/2 P: I#86-H
M92!,:6YE(%-I>F4](#!H( I0<FEM87)Y($)U<R!.=6UB97(@(" @(" @/2 P
M: I396-O;F1A<GD@0G5S($YU;6)E<B @(" @/2 Q: I3=6)O<F1I;F%T92!"
M=7,@3G5M8F5R(" @/2 Q: I396-O;F1A<GD@3&%T96YC>2!4:6UE<B @/2 P
M: I)+T@0F%S92 @(" @(" @(" @(" @(" @/2!F,6@*22]/($QI;6ET(" @
M(" @(" @(" @(" @(#T@,6@*4V5C;VYD87)Y(%-T871U<R @(" @(" @(#T@
M,C(X,&@*365M;W)Y($)A<V4@(" @(" @(" @(" @(#T@9F9F,&@*365M;W)Y
M($QI;6ET(" @(" @(" @(" @(#T@,&@*4’)E9F5T8VAA8FQE($UE;6]R>2!"
M87-E(#T@9F9F,6@4’)E9F5T8VAA8FQE($UE;6]R>2!,:6UI=#T@,6@4’)E
M9F5T8VAA8FQE($)A<V4@57!P97(@,S(@0FET<R @/2 P: I0<F5F971C:&%B
M;&4@3&EM:70@57!P97(@,S(@0FET<R ](#!H"DDO3R!“87-E(%5P<&5R(#$V
M($)I=’,@(” ](#!H"DDO3R!,:6UI="!5<’!E<B Q-B!":71S(" ](#!H"D)R
M:61G92!#;VYT<F]L(" @(" @(" @(" ](#!N<PI00TD@26YT(%!I;B @(" @
M(" @(" @(" @/2!.0PI);G1E<G)U<‘0@;&EN92 @(" @(" @(" @/2 P"@I#
M;&%S<R @(" @(" @(" ]($YE=’=O<FL@
$5T:&5R;F5T
0I696YD;W(@240@
M(" @(" ](#$P8C=H+" S0V]M($-O<G!O<F%T:6]N( I$979I8V4@240@(" @
M(" ](#DP-3!H+" S0SDP-2U46"!&87-T($5T:&5R;&EN:R!83"!00TD@,3 O
M,3 P"E!#22!I;F1E>" @(" @(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P,C P
M,#!H"E)E=FES:6]N($E$(" @(#T@,&@*0G5S(&YU;6)E<B @(" @/2 P"D1E
M=FEC92!N=6UB97(@(#T@,3(1G5N8W1I;VX@;G5M(" @/2 P"E-T871U<R!2
M96<@(" @(#T@,C P: I#;VUM86YD(%)E9R @(" ](#$P-6@2&5A9&5R('1Y
M<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX
0DE35" @(" @(" @(" @/2 P
M:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O<G1E9 I,871E;F-Y(%1I
M;65R(" ](#$X: I#86-H92!,:6YE(%-I>F4](#!H( I)3R!!9&1R97-S(" @
M(" ](#$P,#!H(&QE;F=T:" V-"!E;F%B;&5D"D5X<&%N<VEO;B!23TT@(#T@
M9F9E9C P,#!H(&QE;F=T:" V-34S-B!D:7-A8FQE9 I-87@@3&%T(" @(" @
M(" ](#AN<PI-:6X@1VYT(" @(" @(" ](#-N<PI00TD@26YT(%!I;B @(" ]
M($E.5"!!“DEN=&5R<G5P=”!L:6YE(#T@,3$
“D-L87-S(” @(" @(" @(#T@
M36%S<R!3=&]R86=E(“A)1$4I"E9E;F1O<B!)1” @(" @(#T@,3 T-6@L($]0
M5&D@26YC+B *1&5V:6-E($E$(" @(" @/2!C-C(Q:“P@.#)#-C(Q(%!#22!)
M1$4@0V]N=’)O;&QE<B H4$E#*0I00TD@:6YD97@@(” @(" ](#!H"D-L87-S
M($-O9&5S(" @(#T@,#$P,3AA: I2979I<VEO;B!)1" @(" ](#$Q: I"=7,@
M;G5M8F5R(" @(" ](# *1&5V:6-E(&YU;6)E<B @/2 R, I&=6YC=&EO;B!N
M=6T@(" ](# 4W1A=‘5S(%)E9R @(" @/2 R.#!H"D-O;6UA;F0@4F5G(" @
M(#T@,6@2&5A9&5R('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX0DE3
M5" @(" @(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O
M<G1E9 I,871E;F-Y(%1I;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@
M"DE/($%D9’)E<W,@(" @(#T@,F,T,&@@;&5N9W1H(#$V(&5N86)L960
36%X
M($QA=" @(" @(" @/2 P;G,*36EN($=N=" @(" @(" @/2 P;G,*4$-)($EN
M="!0:6X@(" @/2!.0PI);G1E<G)U<'0@;&EN92 ](# *“D-L87-S(” @(" @
M(" @(#T@375L=&EM961I82 H5FED96\I"E9E;F1O<B!)1" @(" @(#T@,3(Q
M86@L(#-D9G@@26YT97)A8W1I=F4@26YC( I$979I8V4@240@(" @(" ](#)H
M+"!6;V]D;V\R(%9O;V1O;R R(#-$($%C8V5L97)A=&]R"E!#22!I;F1E>" @
M(" @(#T@,&@*0VQA<W,@0V]D97,@(" @/2 P-# P,#!H"E)E=FES:6]N($E$
M(" @(#T@,F@*0G5S(&YU;6)E<B @(" @/2 Q"D1E=FEC92!N=6UB97(@(#T@
M- I&=6YC=&EO;B!N=6T@(" ](# *4W1A='5S(%)E9R @(" @/2!A,&@*0V]M
M;6%N9"!296<@(" @/2 P: I(96%D97(@='EP92 @(" ](#!H(%-I;F=L92UF
M=6YC=&EO;@I"25-4(" @(" @(" @(" ](#!H($)U:6QD+6EN+7-E;&8M=&5S
M="!N;W0@<W5P<&]R=&5D"DQA=&5N8WD@5&EM97(@(#T@,&@0V%C:&4@3&EN
M92!3:7IE/2 P:" 365M($%D9’)E<W,@(" @/2 P:"!P<F5F971C:&%B;&4@
M,S)B:70@;&5N9W1H(#$V-S<W,C$V(&1I<V%B;&5D"DUA>"!,870@(" @(" @
M(#T@,&YS"DUI;B!’;G0@(" @(" @(#T@,&YS"E!#22!);G0@4&EN(" @(#T@
M3D,26YT97)R=7!T(&QI;F4@/2 P"@I#;&%S<R @(" @(" @(" ]($UU;'1I
M;65D:6$@
%9I9&5O
0I696YD;W(@240@(" @(" ](#$R,6%H+" S9&9X($EN
M=&5R86-T:79E($EN8R 1&5V:6-E($E$(" @(" @/2 R:“P@5F]O9&]O,B!6
M;V]D;V@,B S1”!!8V-E;&5R871O<@I00TD@:6YD97@@(" @(" ](#%H"D-L
M87-S($-O9&5S(" @(#T@,#0P,# P: I2979I<VEO;B!)1" @(" ](#)H"D)U
M<R!N=6UB97(@(" @(#T@,0I$979I8V4@;G5M8F5R(" ](#4
1G5N8W1I;VX@
M;G5M(" @/2 P"E-T871U<R!296<@(" @(#T@83!H"D-O;6UA;F0@4F5G(" @
M(#T@,&@2&5A9&5R('1Y<&4@(" @/2 P:"!3:6YG;&4M9G5N8W1I;VX0DE3
M5" @(" @(" @(" @/2 P:"!"=6EL9"UI;BUS96QF+71E<W0@;F]T(’-U<’!O
M<G1E9 I,871E;F-Y(%1I;65R(" ](#!H"D-A8VAE($QI;F4@4VEZ93T@,&@@
M"DUE;2!!9&1R97-S(" @(#T@,&@@<’)E9F5T8VAA8FQE(#,R8FET(&QE;F=T
M:" Q-C<W-S(Q-B!D:7-A8FQE9 I-87@@3&%T(" @(" @(" ](#!N<PI-:6X@
M1VYT(" @(" @(" ](#!N<PI00TD@26YT(%!I;B @(" ]($Y#“DEN=&5R<G5P
,=”!L:6YE(#T@, H

`
end

Hugh Brown (613) 591-0931 ext. 209 (voice)
QNX Software Systems Ltd. (613) 591-3579 (fax)
175 Terence Matthews Cres. email: hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8

See below …

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
I’m a little bit lost!!!

When we write a simple server application which is able to create
thread we need to have something like:

typedef union{
struct _pulse pulse;
struct my_message msg;
}msg_t;


msg_t msg;

rcvid = MsgReceive(…)

switch (rcvid)
{
case 0:
switch(msg.pulse.code)
{
case _PULSE_CODE_DISCONNECT:
ConnectDetach(Msg.pulse.scoid);
break;
}
break;

}



Now consider a server application developped as a ressource manager,

able to receive IO_MSG and able to create a thread to do something,
depending on the received message.
the message type is:

typedef union{
struct _io_msg io_msg;
struct _pulse pulse;
};

In the application we have:

for_ever{
ctp = dispatch_block(ctp);

dispatch_handler(ctp);
}

My problem is how can I catch the pulse to call the
ConnectDetach()??

Do you mean the _PULSE_CODE_DISCONNECT pulse from clients that have
open()ed your resource manager’s registered name? If yes then don’t
worry about it. The resource manager library already handles this
pulse by doing the ConnectDetach(scoid).

No, I want to talk about the _PULSE_CODE_DISCONNECT that I’m supposed to
receive (I think) when my ressource manager kill a thread
(pthread_cancel()) it has created to perform a task.


I have a second problem which maybe is the same.


After I killed the thread, my ressource manager exits, why ??

Do you think this problem can be a result of something I missed after
calling pthread_cancel() ?

— In fact I’m sure that pthread_cancel() is the cause of my problem
because without it, my ressource manager isn’t killed.
I add that my ressource manager exits normally, that is, without any
error message.
My problem is that I don’t know why killing a child, also kill the
parent in this case.


Third, If I printf() the message type received I see the following
sequence:

IO_CONNECT
^ client open()s, open() sends this

IO_MSG
^ client sends IO_MSG

IO_CLOSE
^ client calls close(), close() sends IO_CLOSE message

0
^ the _PULSE_CODE_DISCONNECT pulse, close() calls ConnectDetach(fd)



What is 0 (zero)?

Thanks Alain.

Ok for that.

Thanks
Alain.

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Now consider a server application developped as a ressource manager,
able to receive IO_MSG and able to create a thread to do something,
depending on the received message.
the message type is:

typedef union{
struct _io_msg io_msg;
struct _pulse pulse;
};

In the application we have:

for_ever{
ctp = dispatch_block(ctp);

dispatch_handler(ctp);
}

My problem is how can I catch the pulse to call the
ConnectDetach()??

Do you mean the _PULSE_CODE_DISCONNECT pulse from clients that have
open()ed your resource manager’s registered name? If yes then don’t
worry about it. The resource manager library already handles this
pulse by doing the ConnectDetach(scoid).

No, I want to talk about the _PULSE_CODE_DISCONNECT that I’m supposed to
receive (I think) when my ressource manager kill a thread
(pthread_cancel()) it has created to perform a task.

Okay, it is the _PULSE_CODE_THREADDEATH that you’re supposed to
receive when your resource manager kills a thread that belongs to
the same process. It mystifies me as to why you (and I) get this
though since _NTO_CHF_THREAD_DEATH is not being set on the resource
manager’s channel.

Can you post the exact code snippet for your dispatch loop?

I have a second problem which maybe is the same.


After I killed the thread, my ressource manager exits, why ??

This may be a bug. I’ll wait until I see the above requested code
snippet before saying more though.

Do you think this problem can be a result of something I missed after
calling pthread_cancel() ?

— In fact I’m sure that pthread_cancel() is the cause of my problem
because without it, my ressource manager isn’t killed.
I add that my ressource manager exits normally, that is, without any
error message.
My problem is that I don’t know why killing a child, also kill the
parent in this case.



Third, If I printf() the message type received I see the following
sequence:

IO_CONNECT
^ client open()s, open() sends this

IO_MSG
^ client sends IO_MSG

IO_CLOSE
^ client calls close(), close() sends IO_CLOSE message

0
^ the _PULSE_CODE_DISCONNECT pulse, close() calls ConnectDetach(fd)



What is 0 (zero)?

Thanks Alain.

Ok for that.

Thanks
Alain.

Shane Warren wrote:

Has anyone had any luck compiling and installing Python 2.0?

About 3 weeks ago I had a go at getting Python 1.6 going on the RTP and I
had pretty good success, so today I’m trying to get 2.0 going its a bit
different than 1.6 so here goes…

I’ve got Python 2.0 to compile by editing a couple .c files. Now I’m trying
to get “make test” to work (it locks up on test_signal).

They are using SIG_DFL to catch SIGALRM … but
the shell doesn’t handle the
SIGCLD correctly (?) IMHO the haven’t set
SA_NOCLDSTOP … so it is probably a shell
problem? (That problem is not existing with QNX4
… compiled with Watcom 10.6)

It looks like
everything else works ok (except test_re which does some weird overflow test
that sigsev’s, I fixed it by editing the test).

I will discuss it with the author …

BTW … I have setted up a project at
sourceforge.net … look for
PyQNX. I will post in the next days the 2.0
version for QNX4 and RTP.
(pyqnx.sourceforge.net not yet available … )

Armin
http://www.steinhoff.de/python_tilcon.html

I have some questions about RTP’s memory management.

  1. What is the page size being used?

It is 4K. You can find this out by using the getconf utility which
generally exists on POSIX compliant systems:

$ getconf PAGESIZE
4096

Also this can be found in code by using (slightly modified from our helpviewer
doc on sysconf):

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <unistd.h>

int main( void )
{
printf( “_SC_PAGE_SIZE = %ld\n”, sysconf( _SC_PAGE_SIZE ) );
return EXIT_SUCCESS;
}


Again the sysconf() function is POSIX and exists on many other systems.

A 4K page size is common to most OS’s.

  1. What is the logical address size ( I think how much memory can be
    addressed)?

This is 4 GB. This is more of an architechure dependent thing than OS dependent. I believe other OS’s such as NT and Linux, running on x86 (32 bit addressing, 2^32 = 4 GB) will all be the same.


This is for a class project and I can’t figure out how to determine this
from the os itself. Thanks.

Ross Brantner

I have a similar product by MacSense the MIH-130. All I did was select DHCP in Network Config /devices (phlip). I may have entered the defualt gateway (your router address) and name servers as well - but I think that DHCP should detect them for you.

You need to insure that you ethernet card is running properly

Previously, Jeff Pynnonen wrote in qdn.public.qnxrtp.installation, qdn.public.qnxrtp.os:

I have a Linksys Etherfast Cable/DSL Router BEFSR41. It provides a DHCP
server, internet firewall, and router for
a small network. It works great with my PCs and Power PC Mac, but I
can’t get it to work with QNX. I attach to the
internet via DSL and a static IP.

Has anyone got to the internet thru the Linksys Cable/DSL Router with
QNX?
It seems to recognize my no-name Ethernet card just fine.
\


David L. Hawley D.L. Hawley and Associates

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 ??

Armin

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 :slight_smile:

  • igor

Igor Kovalenko 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.

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

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.

Yes … and it will be discussed again and again
as long as that workaround and the differences of
their mmap implementation isn’t documented.

But yes, I want them to get it fully working too, eventually > :slight_smile:

If QSSL would really open up their sources … it
would probbaly a way to get VM.

Armin

  • igor

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 > :slight_smile:

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.

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).

Regards,
Eric

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 > :slight_smile:

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

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.

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 :slight_smile: 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.
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.

Sunil.

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 > :slight_smile:

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

“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A24B7C9.A1403F28@web_.de…

Igor Kovalenko 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.

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

You really have a way to bring out the best in people Armin, keep it up.

  • Mario