io-net

QNX Newsgroups (Archives) comp.os.qnx
1

Folks,
I have a couple of questions about io-net. I’m working on a filter. My
filter will be a shared object that gets mounted into io-net. Is the driver
that drives the ethernet chipset also a shared object? What I’m getting at
is that if both of these things run in io-net’s context, when the driver
calls it’s tx_up() my rx_up() gets called. There is no context switching
going on, just a function call or two, right?

Next question. Does io-net provide each module’s function handles to the
other modules? In other words, when the driver calls tx_up() is it actually
calling the rx_up() function of the next layer up ( my filter in this
case )? In that model, there would only be one function call overhead to
exchange packets from one layer to the next. Or is it the case that tx_up()
is sending things into io-net, which then figures out who’s rx_up() to call
with the same data? This would indicate (slightly) more overhead.
TIA!
Chris

2

I have a couple of questions about io-net. I’m working on a filter. My
filter will be a shared object that gets mounted into io-net. Is the driver
that drives the ethernet chipset also a shared object? What I’m getting at
is that if both of these things run in io-net’s context, when the driver
calls it’s tx_up() my rx_up() gets called. There is no context switching
going on, just a function call or two, right?

Basically correct. Sometimes there are different threads moving about
depending on how the protocols and drivers are written.

Next question. Does io-net provide each module’s function handles to the
other modules? In other words, when the driver calls tx_up() is it actually
calling the rx_up() function of the next layer up ( my filter in this
case )? In that model, there would only be one function call overhead to
exchange packets from one layer to the next. Or is it the case that tx_up()
is sending things into io-net, which then figures out who’s rx_up() to call
with the same data? This would indicate (slightly) more overhead.

There is slightly more overhead since, for example, there could be multiple
filters and converters above a driver and they can all change at runtime.
But two function calls vs. one is hardly much overhead at all.

chris


\

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

3

Anyone have any hints as to why the included code fails to work?
Seems to me it should just pass through all the packets, setting the
appropriate LEDs.
Anything obvious I’ve missed?
TIA
Chris


BPC Software Group <bpc_sw@hotmail.com> wrote in message
news:9u0tji$n9v$1@inn.qnx.com…

Folks,
I have a couple of questions about io-net. I’m working on a filter. My
filter will be a shared object that gets mounted into io-net. Is the
driver
that drives the ethernet chipset also a shared object? What I’m getting
at
is that if both of these things run in io-net’s context, when the driver
calls it’s tx_up() my rx_up() gets called. There is no context switching
going on, just a function call or two, right?

Next question. Does io-net provide each module’s function handles to the
other modules? In other words, when the driver calls tx_up() is it
actually
calling the rx_up() function of the next layer up ( my filter in this
case )? In that model, there would only be one function call overhead to
exchange packets from one layer to the next. Or is it the case that
tx_up()
is sending things into io-net, which then figures out who’s rx_up() to
call
with the same data? This would indicate (slightly) more overhead.
TIA!
Chris
\

begin 666 etherDrvr.c
M+R@(&5T:&5R1’)V<BYC"B\O("!A(‘1E<W0@=&@<V5E(&EF($D@8V%N(&=E
M;F5R871E(&%N($5T:&5R;F5T(&9I;‘1E<B!T:&%T(&AO;VMS(&EN=&@:6\M
M;F5T"B\O("!A;F0@<V5E<R!A;&P@=&AE(’!A8VME=’,@9FQO=VEN9R!B>2!I
M;B!B;W1H(&1I<F5C=&EO;G,N"B\O(" +R@(%1H92!G96YE<F%L(&ED96$@
M:7,@=&@:&]O:R!I;B!A<R!A(&9I;'1E<B!J=7-T(&%B;W9E(‘1H90HO+R @
M=‘5L:7 @9’)I=F5R+@HO+R @“B\O(”!#:’)I<R!“96%S;&5Y+”!“97)K96QE
M>2!0<F]C97-S($-O;G1R;VPL($EN8RX@,C P,0HO+R @”@HC:6YC;'5D92 B
M;&5D+F@B"B-I;F-L=61E(#QH=R]I;F]U="YH/@HC:6YC;'5D92 <WES+VUM
M86XN:#X"B-I;F-L=61E(#QS>7,O:6\M;F5T+F@^“B-I;F-L=61E(#QI;G1T
M>7!E<RYH/@HC:6YC;‘5D92 \871O;6EC+F@^"B-I;F-L=61E(#QU;FES=&0N
M:#X*(VEN8VQU9&4@/’-T9&EO+F@^“B-I;F-L=61E(#QS=’)I;F=S+F@^“B-I
M;F-L=61E(#QE<G)N;RYH/@HC:6YC;'5D92 ;F5T+VEF+F@^“B-I;F-L=61E
M(#QN970O:69?=‘EP97,N:#X*“B-U;F1E9B @4TA/4E1?3$5$7T1%3$%9"B-D
M969I;F4@4TA/4E1?3$5$7T1%3$%9(#!X-&9F9F9F"B-D969I;F4@35154TE:
M12 Q-3$T"B-D969I;F4@4$%#2T547U-)6D4@-3 (V1E9FEN92!004-+151?
M24Y?55-%("@P>#$@/#P@,S$I"@H:6YT(&UY7VEN:70H('9O:60@F1L;%]H
M9&PL"@D@(" @9&ES<&%T8VA?=" J9’!P+ H)(" @(&EO7VYE=%]S96QF7W0@
MFEO;BP*“2 @(”!C:&%R(“IO<‘1I;VYS(“D[”@IV;VED("IM>5]R>%]T:’)E
M860H('9O:60@F%R9R I.PII;G0@;7E?='A?9&]N92@@;G!K=%]T(“IN<&MT
M+”!V;VED("ID;VYE7VAD;“P@=F]I9” J9G5N8U]H9&P@3L:6YT(&UY7W)X
M7W5P”!N<&MT7W0@FYP:W0L"@D@(" @(‘9O:60@F9U;F-?:&1L+ H)(" @
M("!I;G0@;V9F+ H)(" @("!I;G0@9G)A;6QE;E]S=6(L"@D@(" @('5I;G0Q
M-E]T(&-E;&PL"@D@(" @(‘5I;G0Q-E]T(&5N9’!O:6YT+ H)(" @("!U:6YT
M,39?="!I9F%C92 I.PH:6YT(&UY7W)X7V1O=VXH(&YP:W1?=" J;G!K=“P@
M=F]I9” J9G5N8U]H9&P@3L:6YT(&UY7W-H=71D;W=N,2@@:6YT(’)E9VES
M=’)A;G1?:&1L+"!V;VED(“IF=6YC7VAD;” I.PII;G0@;7E?<VAU=&1O=VXR
M”!I;G0@<F5G:7-T<F%N=%]H9&PL(‘9O:60@F9U;F-?:&1L(“D[”@H+R@
M1VQO8F%L(’-Y;6)O;’,=F]I9" J;7E?9&QL7VAD;#L:6]?;F5T7W-E;&9?
M=” J;7E?:6]N.PII;G0@;7E?<F5G7VAD;#L*=6EN=#$V7W0@;7E?8V5L;#L*
M=6EN=#$V7W0@;7E?96YD<&]I;G0[”@II;U]N971?9&QL7V5N=’)Y7W0@:6]?
M;F5T7V1L;%]E;G1R>2 ]“GL*(” @,BP@(” @(” @+R@3G5M8F5R(&]F(&9U
M;F-T:6]N<PH@("!M>5]I;FET+" O+R!I;FET*“D*(” @3E5,3" @(" @+R@
M(FUA<W1E<B(@<VAU=&1O=VXH0I].PH"B\O(&9U;F-T:6]N<R!T:&%T(’=E
M(’-U<’!L>0II;U]N971?<F5G:7-T<F%N=%]F=6YC<U]T(&UY7V9U;F-S(#T*
M>PH@("!?24]?3D547U)%1U].1E5.0U,L(" @("\O(&YF=6YC<PH@(" @(&UY
M7W)X7W5P+" @(" @(" @(" @(" @+R@<F5C96EV92!A(’!A8VME="!O;B!I
M="=S(’=A>2!U< H@(" @(&UY7W)X7V1O=VXL(" @(" @(" @(" @+R@<F5C
M96EV92!A(’!A8VME="!O;B!I="=S(’=A>2!D;W=N"B @(" @;7E?='A?9&]N
M92P@(" @(" @(" @(" O+R!R96QE87-E(&]U<B!H;VQD(&$@<&%C:V5T"B @
M(" @;7E?<VAU=&1O=VXQ+" @(" @(" @(" O+R!S:‘5T9&]W;C$H0H@(" @
M(&UY7W-H=71D;W=N,BP@(" @(" @(" @+R@<VAU=&1O=VXR"D*(" @("!.
M54Q,+" @(" @(" @(" @(" @(" @("\O(&1L7V%D=F5R="@I"B @(" @3E5,
M3"P@(" @(" @(" @(" @(" @(" O+R!D979C=&PH0H@(" @($Y53$PL(" @
M(" @(" @(" @(" @(" @+R@9FQU<V@H0H@(" @($Y53$PL(" @(" @(" @
M(" @(" @(" @+R@<F%W7V]P96XH0H@(" @($Y53$P?3L*(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" +R@82!D97-C<FEP
M=&EO;B!O9B!O=7(@9’)I=F5R"FEO7VYE=%]R96=I<W1R86YT7W0@;7E?96YT
M<GD@/0I[“B @(” @7U)%1U]&24Q415)?0D5,3U<L("\O('P@7U)%1U])3DE4
M7T].0T4L("!W:&5R92!T:&4@9B,H)2!I<R!?:6YI=%]O;F-E(&1E9FEN960A
M/PH@(" @(")B<&,M:7 M9FEL=&5R+G-O(BPO+R!O=7(@;F%M90H@(" @(")I
M<"(L(" @(" @(" @(" @(" O+R!O=7(@=&]P('1Y<&4(" @(" B:7 B+" @
M(" @(" @(" @(" @+R@;W5R(&)O=‘1O;2!T>7!E"B @(" @3E5,3"P@(" @
M(" @(" @(" @("\O(&=L;V)A;"!C;VYT<F]L(&AA;F1L90H@(" @(“9M>5]F
M=6YC<RP@(” @(" @(" O+R!P;VEN=&5R(‘1O(&]U<B!F=6YC=&EO;G,(" @
M(" P(" @(" @(" @(" @(" @(" @+R@(V1E<&5N9&5N8VEE<PI].PH"B\O
M9&5B=6<@9G5N8W1I;VYS"G5I;G1P=’)?="!L961?:&%N9&P["@IV;VED(&QE
M9%]I;FET*"!V;VED(“D*>PH@(”!S:7IE7W0@;&5N(#T@.#L*“B @(&QE9%]H
M86YD;” ](&UM87!?9&5V:6-E7VEO("@@;&5N+"!,141?041$4D534R I.PD*
M"B @(%1H<F5A9$-T;"@@7TY43U]40U1,7TE/+"!.54Q,(“D[“GT*“G9O:60@
M;&5D*”!I;G0@=VAI8V@L(&EN=”!D=7)A=&EO;B I"GL*(” @;W5T." H(&QE
M9%]H86YD;“P@=VAI8V@@3L(” @=VAI;&4@"!D=7)A=&EO;BTM(“D[”@H@
M("!R971U<FX["GT"@HO+R @5&AE(&1L;"!F=6YC=&EO;G,N"FEN="!M>5]I
M;FET("AV;VED(“ID;&Q?:&1L+”!D:7-P871C:%]T("ID<’ L(&EO7VYE=%]S
M96QF7W0@FEO;BP@8VAA<B J;W!T:6]N<RD>PH@("!M>5]D;&Q?:&1L(#T@
M9&QL7VAD;#L*(" @;7E?:6]N(#T@:6]N.PH*(" @;&5D7VEN:70H3L(" @
M;&5D*" P># L(%-(3U)47TQ%1%]$14Q!62 I.PH@(" (" @+R@4F5G:7-T
M97(@=VET:"!I;RUN970(" @:68@"@J;7E?:6]N("T^(’)E9RD(" @(" @
M("AM>5]D;&Q?:&1L+ H))FUY7V5N=’)Y+ H))FUY7W)E9U]H9&PL"@DF;7E?
M8V5L;“P*“29M>5]E;F1P;VEN=“D@/” P0H@(" @( H@(" @('L(” @(” @
M<F5T=7)N*" M,2 I.PH@(" @(‘T*(" @;&5D*" P>#$L(%-(3U)47TQ%1%]$
M14Q!62 I.PH*(" @<F5T=7)N("@P3L@(" @(" @(" O+R!S=6-C97-S"GT
M"@II;G0@;7E?=‘A?9&]N92@@;G!K=%]T(“IN<&MT+”!V;VED(“ID;VYE7VAD
M;“P@=F]I9” J9G5N8U]H9&P@0I[“B @(&QE9”@@,’@V+"!32$]25%],141?
M1$5,05D@3L(" @“B @(’)E='5R;B P.PI]”@D@(" @(" @( II;G0@;7E?
M<GA?=7 H(&YP:W1?=" J;G!K="P"2 @=F]I9” J9G5N8U]H9&PL"@D@(&EN
M="!O9F8L"@D@(&EN="!F<F%M;&5N7W-U8BP*“2 @=6EN=#$V7W0@8V5L;“P*
M"2 @=6EN=#$V7W0@96YD<&]I;G0L”@D@('5I;G0Q-E]T(&EF86-E(“D*>PH@
M(”!L960H(#!X-“P@4TA/4E1?3$5$7T1%3$%9(“D[“B @( H@(” HFUY7VEO
M;BT^='A?=7 I”!M>5]R96=?:&1L+”!N<&MT+”!O9F8L(&9R86UL96Y?<W5B
M+"!C96QL+"!E;F1P;VEN=“P@:69A8V4@3L"B @(&QE9”@@,‘A!+"!32$]2
M5%],141?1$5,05D@3L(" @<F5T=7)N($5/2SL*?0H*“FEN=”!M>5]R>%]D
M;W=N*"!N<&MT7W0@FYP:W0L('9O:60@F9U;F-?:&1L("D>PH@("!L960H
M(#!X-2P@4TA/4E1?3$5$7T1%3$%9(“D[”@H@("!R971U<FX@“IM>5]I;VXM
M/G1X7V1O=VXI*”!M>5]R96=?:&1L+"!N<&MT("D[“GT*“FEN=”!M>5]S:'5T
M9&]W;C$H(&EN=”!R96=I<W1R86YT7VAD;“P@=F]I9” J9G5N8U]H9&P@0I[
M"B @(&QE9"@@,'A%+"!32$]25%],141?1$5,05D@3L(" @<F5T=7)N($5/
M2SL@("\O("!R971U<FX@14)54UD@:68@=V4@9&]N)W0@=V%N="!T:&5M(‘1O
M(’-H=70@=7,@9&]W;B!Y970?0H*:6YT(&UY7W-H=71D;W=N,B@@:6YT(’)E
M9VES=’)A;G1?:&1L+"!V;VED(“IF=6YC7VAD;” I"GL*(" @;&5D*" P>$8L
M(%-(3U)47TQ%1%]$14Q!62 I.PH@("!R971U<FX@,#L@("\O("!A="!T:&ES
M(’!O:6YT+"!W92!H879E(&YO(&-H;VEC92!A;F0@;75S="!S:'5T9&]W;@I]
!"@``
`
end

4

Ok, here’s a somewhat easier question: How can I debug this routine?
So far I have been making do with the Hex LED.

Printf’s don’t seem to work, which I guess makes sense since it’s a shared
object. Is there some way to fix printf?

What about gdb? How would I go about debugging something that is a shared
object that plugs into io-net with mount?
Thanks!
chris


BPC Software Group <bpc_sw@hotmail.com> wrote in message
news:9u61uf$go0$1@inn.qnx.com…

Anyone have any hints as to why the included code fails to work?
Seems to me it should just pass through all the packets, setting the
appropriate LEDs.
Anything obvious I’ve missed?
TIA
Chris


BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
news:9u0tji$n9v$> 1@inn.qnx.com> …
Folks,
I have a couple of questions about io-net. I’m working on a filter. My
filter will be a shared object that gets mounted into io-net. Is the
driver
that drives the ethernet chipset also a shared object? What I’m getting
at
is that if both of these things run in io-net’s context, when the driver
calls it’s tx_up() my rx_up() gets called. There is no context
switching
going on, just a function call or two, right?

Next question. Does io-net provide each module’s function handles to
the
other modules? In other words, when the driver calls tx_up() is it
actually
calling the rx_up() function of the next layer up ( my filter in this
case )? In that model, there would only be one function call overhead
to
exchange packets from one layer to the next. Or is it the case that
tx_up()
is sending things into io-net, which then figures out who’s rx_up() to
call
with the same data? This would indicate (slightly) more overhead.
TIA!
Chris


\

5

Ok, I figured out that the printf is working, it’s going to the serial
console, where I did not have anything hooked up.

I have determined that when I fire up this example program I get a certain
sequence of packets every time. I get a message going up which is a ADVERT
type of message. Do I need to do something special with this or is passing
it up with tx_up() ok? Is io-net ( or one of the other modules ) trying to
query me for my module’s capabilities?

Next I get a regular packet going down, I send it down with tx_down(). The
next packet is another message going down that is a message add address type
of message. Again, do I need to do something special with this or just pass
it on?

In general, is there any documentation on how to do what I am trying to do?
White papers? Maybe a QNX programming book I could buy? I have Rob Krten’s
book and while it’s excellent, it’s pretty introductory.
Thanks!
chris

BPC Software Group <bpc_sw@hotmail.com> wrote in message
news:9u6cnp$n4r$1@inn.qnx.com…

Ok, here’s a somewhat easier question: How can I debug this routine?
So far I have been making do with the Hex LED.

Printf’s don’t seem to work, which I guess makes sense since it’s a shared
object. Is there some way to fix printf?

What about gdb? How would I go about debugging something that is a shared
object that plugs into io-net with mount?
Thanks!
chris


BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
news:9u61uf$go0$> 1@inn.qnx.com> …
Anyone have any hints as to why the included code fails to work?
Seems to me it should just pass through all the packets, setting the
appropriate LEDs.
Anything obvious I’ve missed?
TIA
Chris


BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
news:9u0tji$n9v$> 1@inn.qnx.com> …
Folks,
I have a couple of questions about io-net. I’m working on a filter.
My
filter will be a shared object that gets mounted into io-net. Is the
driver
that drives the ethernet chipset also a shared object? What I’m
getting
at
is that if both of these things run in io-net’s context, when the
driver
calls it’s tx_up() my rx_up() gets called. There is no context
switching
going on, just a function call or two, right?

Next question. Does io-net provide each module’s function handles to
the
other modules? In other words, when the driver calls tx_up() is it
actually
calling the rx_up() function of the next layer up ( my filter in this
case )? In that model, there would only be one function call overhead
to
exchange packets from one layer to the next. Or is it the case that
tx_up()
is sending things into io-net, which then figures out who’s rx_up() to
call
with the same data? This would indicate (slightly) more overhead.
TIA!
Chris




\

6

BPC Software Group <bpc_sw@hotmail.com> wrote:

Ok, I figured out that the printf is working, it’s going to the serial
console, where I did not have anything hooked up.

I have determined that when I fire up this example program I get a certain
sequence of packets every time. I get a message going up which is a ADVERT
type of message. Do I need to do something special with this or is passing
it up with tx_up() ok? Is io-net ( or one of the other modules ) trying to
query me for my module’s capabilities?

That is up to you. If you are doing a filter layer then you may want to use
the advertise messages to track when you need to start filtering for a new
device or protocol. Generally you will just pass things thru.

chris

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

7

Try fprintf to stderr instead of printf

Poseidon

8

Couple points on your code:

_REG_INIT_ONCE was renamed _REG_NO_REMOUNT to better reflect what it
actually does.

If you want to be above an ethernet driver as your comment suggests,
you want to be a _REG_FILTER_ABOVE with top_type “en”, bot_type “en”.

In my_init(), you’ll want to to a
my_ion->reg_byte_pat(my_reg_hdl, 0, 0, NULL, _BYTE_PAT_ALL) to receive
all up headed ethernet packets.

in my_rx_up, you need to look at the return from my_ion->tx_up(),
if it’s == 0, you need to call my_ion->tx_done(my_reg_hdl, npkt).

-seanb


BPC Software Group <bpc_sw@hotmail.com> wrote:
: Anyone have any hints as to why the included code fails to work?
: Seems to me it should just pass through all the packets, setting the
: appropriate LEDs.
: Anything obvious I’ve missed?
: TIA
: Chris


: BPC Software Group <bpc_sw@hotmail.com> wrote in message
: news:9u0tji$n9v$1@inn.qnx.com…
:> Folks,
:> I have a couple of questions about io-net. I’m working on a filter. My
:> filter will be a shared object that gets mounted into io-net. Is the
: driver
:> that drives the ethernet chipset also a shared object? What I’m getting
: at
:> is that if both of these things run in io-net’s context, when the driver
:> calls it’s tx_up() my rx_up() gets called. There is no context switching
:> going on, just a function call or two, right?
:>
:> Next question. Does io-net provide each module’s function handles to the
:> other modules? In other words, when the driver calls tx_up() is it
: actually
:> calling the rx_up() function of the next layer up ( my filter in this
:> case )? In that model, there would only be one function call overhead to
:> exchange packets from one layer to the next. Or is it the case that
: tx_up()
:> is sending things into io-net, which then figures out who’s rx_up() to
: call
:> with the same data? This would indicate (slightly) more overhead.
:> TIA!
:> Chris
:>
:>
:>

9

Thanks, those comments are useful. I have since gotten a copy of the bpf
source from xtang’s
repository and been studying that. I think I want to be an IP filter, and
have since renamed my
code to reflect this. I have added _reg_no_remount, am still
_reg_filter_below, and IP, IP. I have also checked the return type of tx_up
in my rx_up and call tx_done as appropriate.

Will I still need a reg_byte_pat if I am an IP IP filter?

My code still hangs up the stack.

Here’s another question: If I want to receive all up packets ( IP ) but no
down packets, is there a way to do that? Can I do that and still
occasionally generate and tx_down a packet?

Thanks!
Chris


Sean Boudreau <seanb@qnx.com> wrote in message
news:9u87ha$fku$1@nntp.qnx.com…

Couple points on your code:

_REG_INIT_ONCE was renamed _REG_NO_REMOUNT to better reflect what it
actually does.

If you want to be above an ethernet driver as your comment suggests,
you want to be a _REG_FILTER_ABOVE with top_type “en”, bot_type “en”.

In my_init(), you’ll want to to a
my_ion->reg_byte_pat(my_reg_hdl, 0, 0, NULL, _BYTE_PAT_ALL) to receive
all up headed ethernet packets.

in my_rx_up, you need to look at the return from my_ion->tx_up(),
if it’s == 0, you need to call my_ion->tx_done(my_reg_hdl, npkt).

-seanb


BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Anyone have any hints as to why the included code fails to work?
: Seems to me it should just pass through all the packets, setting the
: appropriate LEDs.
: Anything obvious I’ve missed?
: TIA
: Chris


: BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
: news:9u0tji$n9v$> 1@inn.qnx.com> …
:> Folks,
:> I have a couple of questions about io-net. I’m working on a filter.
My
:> filter will be a shared object that gets mounted into io-net. Is the
: driver
:> that drives the ethernet chipset also a shared object? What I’m
getting
: at
:> is that if both of these things run in io-net’s context, when the
driver
:> calls it’s tx_up() my rx_up() gets called. There is no context
switching
:> going on, just a function call or two, right?
:
:> Next question. Does io-net provide each module’s function handles to
the
:> other modules? In other words, when the driver calls tx_up() is it
: actually
:> calling the rx_up() function of the next layer up ( my filter in this
:> case )? In that model, there would only be one function call overhead
to
:> exchange packets from one layer to the next. Or is it the case that
: tx_up()
:> is sending things into io-net, which then figures out who’s rx_up() to
: call
:> with the same data? This would indicate (slightly) more overhead.
:> TIA!
:> Chris
:
:
:

10

Thanks, Sean, it was the reg_byte_pat that finally did it.
Cheers!
Chris


Sean Boudreau <seanb@qnx.com> wrote in message
news:9u87ha$fku$1@nntp.qnx.com…

Couple points on your code:

_REG_INIT_ONCE was renamed _REG_NO_REMOUNT to better reflect what it
actually does.

If you want to be above an ethernet driver as your comment suggests,
you want to be a _REG_FILTER_ABOVE with top_type “en”, bot_type “en”.

In my_init(), you’ll want to to a
my_ion->reg_byte_pat(my_reg_hdl, 0, 0, NULL, _BYTE_PAT_ALL) to receive
all up headed ethernet packets.

in my_rx_up, you need to look at the return from my_ion->tx_up(),
if it’s == 0, you need to call my_ion->tx_done(my_reg_hdl, npkt).

-seanb


BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Anyone have any hints as to why the included code fails to work?
: Seems to me it should just pass through all the packets, setting the
: appropriate LEDs.
: Anything obvious I’ve missed?
: TIA
: Chris


: BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
: news:9u0tji$n9v$> 1@inn.qnx.com> …
:> Folks,
:> I have a couple of questions about io-net. I’m working on a filter.
My
:> filter will be a shared object that gets mounted into io-net. Is the
: driver
:> that drives the ethernet chipset also a shared object? What I’m
getting
: at
:> is that if both of these things run in io-net’s context, when the
driver
:> calls it’s tx_up() my rx_up() gets called. There is no context
switching
:> going on, just a function call or two, right?
:
:> Next question. Does io-net provide each module’s function handles to
the
:> other modules? In other words, when the driver calls tx_up() is it
: actually
:> calling the rx_up() function of the next layer up ( my filter in this
:> case )? In that model, there would only be one function call overhead
to
:> exchange packets from one layer to the next. Or is it the case that
: tx_up()
:> is sending things into io-net, which then figures out who’s rx_up() to
: call
:> with the same data? This would indicate (slightly) more overhead.
:> TIA!
:> Chris
:
:
:

11

So, now that this is working, I’m having some trouble parsing the packet
data. I’m an IP_IP filter, and I would like to start by looking at the
packet’s IP header. I can transit from npkt->buffers(first)->iov to
iov_base pointer. In the case of a message packet, this points to the
message type, a sixteen bit data item. I got that working. In the case of
a data packet, would this point to the start of the IP header? I’m having
trouble making any sense of the data based on that assumption. I have tried
using the htons() family of functions on the data, because my host is LE,
but I still can’t make any sense of the data. Now I’m questinoing my
assumption. Is the first IOV’s iov_base pointer a pointer to the start of
the IP header?
Thanks!
Chris


BPC Software Group <bpc_sw@hotmail.com> wrote in message
news:9uoc6t$368$1@inn.qnx.com…

Thanks, Sean, it was the reg_byte_pat that finally did it.
Cheers!
Chris


Sean Boudreau <> seanb@qnx.com> > wrote in message
news:9u87ha$fku$> 1@nntp.qnx.com> …
Couple points on your code:

_REG_INIT_ONCE was renamed _REG_NO_REMOUNT to better reflect what it
actually does.

If you want to be above an ethernet driver as your comment suggests,
you want to be a _REG_FILTER_ABOVE with top_type “en”, bot_type “en”.

In my_init(), you’ll want to to a
my_ion->reg_byte_pat(my_reg_hdl, 0, 0, NULL, _BYTE_PAT_ALL) to receive
all up headed ethernet packets.

in my_rx_up, you need to look at the return from my_ion->tx_up(),
if it’s == 0, you need to call my_ion->tx_done(my_reg_hdl, npkt).

-seanb


BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Anyone have any hints as to why the included code fails to work?
: Seems to me it should just pass through all the packets, setting the
: appropriate LEDs.
: Anything obvious I’ve missed?
: TIA
: Chris


: BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
: news:9u0tji$n9v$> 1@inn.qnx.com> …
:> Folks,
:> I have a couple of questions about io-net. I’m working on a filter.
My
:> filter will be a shared object that gets mounted into io-net. Is the
: driver
:> that drives the ethernet chipset also a shared object? What I’m
getting
: at
:> is that if both of these things run in io-net’s context, when the
driver
:> calls it’s tx_up() my rx_up() gets called. There is no context
switching
:> going on, just a function call or two, right?
:
:> Next question. Does io-net provide each module’s function handles to
the
:> other modules? In other words, when the driver calls tx_up() is it
: actually
:> calling the rx_up() function of the next layer up ( my filter in this
:> case )? In that model, there would only be one function call
overhead
to
:> exchange packets from one layer to the next. Or is it the case that
: tx_up()
:> is sending things into io-net, which then figures out who’s rx_up()
to
: call
:> with the same data? This would indicate (slightly) more overhead.
:> TIA!
:> Chris
:
:
:

12

BPC Software Group <bpc_sw@hotmail.com> wrote:

So, now that this is working, I’m having some trouble parsing the packet
data. I’m an IP_IP filter, and I would like to start by looking at the
packet’s IP header. I can transit from npkt->buffers(first)->iov to
iov_base pointer. In the case of a message packet, this points to the
message type, a sixteen bit data item. I got that working. In the case of
a data packet, would this point to the start of the IP header? I’m having
trouble making any sense of the data based on that assumption. I have tried
using the htons() family of functions on the data, because my host is LE,
but I still can’t make any sense of the data. Now I’m questinoing my
assumption. Is the first IOV’s iov_base pointer a pointer to the start of
the IP header?

It depends,

If this is a packet from upper, (in you rx_down), the yes.
If this is a packet from below, the iov_base + off is the
start of the ip packet.

All the packet data is be in network order.

-xtang


BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
news:9uoc6t$368$> 1@inn.qnx.com> …
Thanks, Sean, it was the reg_byte_pat that finally did it.
Cheers!
Chris


Sean Boudreau <> seanb@qnx.com> > wrote in message
news:9u87ha$fku$> 1@nntp.qnx.com> …
Couple points on your code:

_REG_INIT_ONCE was renamed _REG_NO_REMOUNT to better reflect what it
actually does.

If you want to be above an ethernet driver as your comment suggests,
you want to be a _REG_FILTER_ABOVE with top_type “en”, bot_type “en”.

In my_init(), you’ll want to to a
my_ion->reg_byte_pat(my_reg_hdl, 0, 0, NULL, _BYTE_PAT_ALL) to receive
all up headed ethernet packets.

in my_rx_up, you need to look at the return from my_ion->tx_up(),
if it’s == 0, you need to call my_ion->tx_done(my_reg_hdl, npkt).

-seanb


BPC Software Group <> bpc_sw@hotmail.com> > wrote:
: Anyone have any hints as to why the included code fails to work?
: Seems to me it should just pass through all the packets, setting the
: appropriate LEDs.
: Anything obvious I’ve missed?
: TIA
: Chris


: BPC Software Group <> bpc_sw@hotmail.com> > wrote in message
: news:9u0tji$n9v$> 1@inn.qnx.com> …
:> Folks,
:> I have a couple of questions about io-net. I’m working on a filter.
My
:> filter will be a shared object that gets mounted into io-net. Is the
: driver
:> that drives the ethernet chipset also a shared object? What I’m
getting
: at
:> is that if both of these things run in io-net’s context, when the
driver
:> calls it’s tx_up() my rx_up() gets called. There is no context
switching
:> going on, just a function call or two, right?
:
:> Next question. Does io-net provide each module’s function handles to
the
:> other modules? In other words, when the driver calls tx_up() is it
: actually
:> calling the rx_up() function of the next layer up ( my filter in this
:> case )? In that model, there would only be one function call
overhead
to
:> exchange packets from one layer to the next. Or is it the case that
: tx_up()
:> is sending things into io-net, which then figures out who’s rx_up()
to
: call
:> with the same data? This would indicate (slightly) more overhead.
:> TIA!
:> Chris
:
:
: