supporting devn-fd

[Rennie_Allen2]

I have a feeling, I’ll figure this out before I get an answer here,
but I don’t understand why I need to work so hard to get this data.

I have written a USB device driver that creates a device that I want
to start devn-fd on.

The question I have is what do I need to support to make devn-fd
happy. I have determined that it uses readcond, and I have
implemented readcond, and I am faithfully doing as it asks (it
is calling readcond(fd,buf,3042,0,0), so my resource manager waits
until 3042 bytes have arrived before replying.

This does not, however, make any sense for a descriptor based net
driver. Do I need to implement ionotify ? I don’t have any problem
doing so, it just seems that implementing features until it works is
a rather brain dead way of going about things.

Why is the source for devn-fd not in the network DDK (it would be
soooo simple if it were) ?

Anyway my question is what does devn-fd expect from its resource
manager ?

Rennie

[ed1k2]

In article <404913F7.5060507@csical.com>, rallen@csical.com says…

Hi Rennie,

I have a feeling, I’ll figure this out before I get an answer here,
but I don’t understand why I need to work so hard to get this data.

Good filling And good question for start

I do not have the answers for your questions, just some thought…

I have written a USB device driver that creates a device that I want
to start devn-fd on.

There was old devn-fd which didn’t work at all (someone from
russian community hacked around it and gave up, because it looked like
without source code it’s easier to write such driver from scratch). Good
one has “adhlc” option in usage message and you need to start the driver
with this option (obviously as well as with “fd” and “mac”).

The question I have is what do I need to support to make devn-fd
happy. I have determined that it uses readcond, and I have
implemented readcond, and I am faithfully doing as it asks (it
is calling readcond(fd,buf,3042,0,0), so my resource manager waits
until 3042 bytes have arrived before replying.

This does not, however, make any sense for a descriptor based net
driver. Do I need to implement ionotify ? I don’t have any problem
doing so, it just seems that implementing features until it works is
a rather brain dead way of going about things.

Why is the source for devn-fd not in the network DDK (it would be
soooo simple if it were) ?

devn-fd was written in mind to work over /dev/ser (I think), i.e. devc-
ser8250 should provide everything to make devn-fd happy. There is the
source of serial driver in character DDK (as well as there is io-char
library source in char DDK of QNX 6.1 release).

Cheers,
Eduard.

Anyway my question is what does devn-fd expect from its resource
manager ?

Rennie

[Rennie_Allen2]

ed1k wrote:

Hi Rennie,

Hi Eduard.

There was old devn-fd which didn’t work at all (someone from
russian community hacked around it and gave up, because it looked like
without source code it’s easier to write such driver from scratch). Good
one has “adhlc” option in usage message and you need to start the driver
with this option (obviously as well as with “fd” and “mac”).

My devn-fd is the good one (it works fine over serial). My problem is with
the silly calls it is making into my resmgr i.e. readcond(fd,buf,3042,0,0) ???

devn-fd does make 2 calls into devctl, reading the termios struct, and
setting it, I emulate this also…

devn-fd was written in mind to work over /dev/ser (I think), i.e. devc-
ser8250 should provide everything to make devn-fd happy. There is the
source of serial driver in character DDK (as well as there is io-char
library source in char DDK of QNX 6.1 release).

Unfortunately devc-* get all their “brains” from libiochar.a. It is basically
impossible to determine what the resmgr side of the interface needs to do
to support devn-fd from examining devc-ser8250 alone…

I am probably going to end up running ppp over my driver anyway (should
remove headers and make it more efficient anyway - it’s one of those “null”
USB cables for hooking 2 pcs together) it’s just it would have been nice
to have the option of either. There is also a much better chance I’ll find
the source to a pppd implementation

Thanks

Rennie

[ed1k2]

In article <c2bms2$ah3$1@inn.qnx.com>, rgallen@attbi.com says…
[X]

Unfortunately devc-* get all their “brains” from libiochar.a. It is basically
impossible to determine what the resmgr side of the interface needs to do
to support devn-fd from examining devc-ser8250 alone…

You’re correct, all resmgr side of the interface is in libio-char.a.
Although QSSL dropped to include source codes of libio-char into
Character DDK since version 6.2.0, there is source code of libio-char in
Character DDK on QNX 6.1 CD, as well as in the on-line CVS rep:
http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/io-char/

I am probably going to end up running ppp over my driver anyway (should
remove headers and make it more efficient anyway - it’s one of those “null”
USB cables for hooking 2 pcs together) it’s just it would have been nice
to have the option of either. There is also a much better chance I’ll find
the source to a pppd implementation >

Well, if you want to play around ppp implementation and its efficiency. I
recently (few months ago) wrote driver for Lava Ether-Link kind of
devices
http://www.lavalink.com/products/ether_serial/prod_ether_serial_dual_port
_rs-232_db-9.html
and tried to connect by QNET 2 PCs together (Ether-Serial converter was
just an RS232 extender to move serial port on a great distance away from
one PC and second PC didn’t have any network card but serial port), both
way over ppp (bind=ip) and by devn-fd. devn-fd worked a bit more
efficient

I still hope someone from QSSL will answer your questions as well.

Eduard.

Thanks

Rennie

[Rennie_Allen2]

ed1k wrote:

You’re correct, all resmgr side of the interface is in libio-char.a.
Although QSSL dropped to include source codes of libio-char into
Character DDK since version 6.2.0, there is source code of libio-char in
Character DDK on QNX 6.1 CD, as well as in the on-line CVS rep:
http://cvs.qnx.com/cgi-bin/cvsweb.cgi/lib/io-char/

Gee, that helps (but not as much as the source to devn-fd would

Well, if you want to play around ppp implementation and its efficiency. I
recently (few months ago) wrote driver for Lava Ether-Link kind of
devices
http://www.lavalink.com/products/ether_serial/prod_ether_serial_dual_port
_rs-232_db-9.html
and tried to connect by QNET 2 PCs together (Ether-Serial converter was
just an RS232 extender to move serial port on a great distance away from
one PC and second PC didn’t have any network card but serial port), both
way over ppp (bind=ip) and by devn-fd. devn-fd worked a bit more
efficient >

I have my driver working with ppp now. It is not as efficient as it
could be. The problem is my driver is essentially a network driver (the
USB cable sends data in 64 byte packets) unfortunately, QNX’s version of
pppd is using the VFWD character (which probably is more efficient on a
real serial port) which means that my driver (which does zero copies -
aside from the write/read into/outof the clients buffer), now has to do
a memchr on each buffer to see if it contains the VFWD character (yuck).

Hopefully, devn-fd does not do this, and it will be a lot more efficient
(the USB cable I have is running the bulk pipe at around 8.6Mbps,
so scanning each packet is painful).

Perhaps I’ll need to migrate it to a real network driver, only problem
there is that I need to have a second device prefix that carriers
completely different data on a different pipe (interrupt pipe), and I
am not sure how easy it is to integrate this into the net DDK.

Eduard.

Thanks for your help…

Rennie “still wants to see the source to devn-fd” Allen

[Xiaodan_Tang1]

Rennie Allen <rgallen@attbi.com> wrote in message
news:c2eb7s$ieh$1@inn.qnx.com…

I have my driver working with ppp now. It is not as efficient as it
could be. The problem is my driver is essentially a network driver (the
USB cable sends data in 64 byte packets) unfortunately, QNX’s version of
pppd is using the VFWD character (which probably is more efficient on a
real serial port) which means that my driver (which does zero copies -
aside from the write/read into/outof the clients buffer), now has to do
a memchr on each buffer to see if it contains the VFWD character (yuck).

Hehe, glad you figured it out. It’s pppd setup the VFWD and want to do
a readcond(). You CAN, however, fail the readcond() request with a
ENOSYS, to claim you don’t support readcond(). In that case, pppd
should fall back with a plain read().

-xtang

Hopefully, devn-fd does not do this, and it will be a lot more efficient
(the USB cable I have is running the bulk pipe at around 8.6Mbps,
so scanning each packet is painful).

Perhaps I’ll need to migrate it to a real network driver, only problem
there is that I need to have a second device prefix that carriers
completely different data on a different pipe (interrupt pipe), and I
am not sure how easy it is to integrate this into the net DDK.

Eduard.

Thanks for your help…

Rennie “still wants to see the source to devn-fd” Allen

[Rennie_Allen2]

Xiaodan Tang wrote:

Rennie Allen <> rgallen@attbi.com> > wrote in message
news:c2eb7s$ieh$> 1@inn.qnx.com> …

Hehe, glad you figured it out. It’s pppd setup the VFWD and want to do
a readcond(). You CAN, however, fail the readcond() request with a
ENOSYS, to claim you don’t support readcond(). In that case, pppd
should fall back with a plain read().

A plain read() of what though ? While it sucks that I have to scan for
VFWD, it still means that pppd has to do the same thing, and if it is
going to issue a read for 1 byte, that isn’t going to be any better.

I am hoping that devn-fd does something like

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, 0);

then, once it has read the packet data size from the ether header,
do something like

readcond(fd, buf, data->size, data->size, 0, timeout);

I also have select() support so it could select for read, then do a

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, timeout);

and the subsequent read of the packet data as above.

either of these mechanisms should be reasonably efficient, since an
ether header fits easily inside a 64 byte USB packet.

So, any clues about what it does (all I have received from it so
far is a readcond for 3042 bytes) ?

ps: devn-fd is far more painful to test with than ppp, since it
can’t be umounted without taking io-net down, and momentics has
a tizzy if io-net goes away.

[Xiaodan_Tang1]

Rennie Allen <rgallen@attbi.com> wrote in message
news:c2gbo8$99v$1@inn.qnx.com…

Xiaodan Tang wrote:
Rennie Allen <> rgallen@attbi.com> > wrote in message
news:c2eb7s$ieh$> 1@inn.qnx.com> …

Hehe, glad you figured it out. It’s pppd setup the VFWD and want to do
a readcond(). You CAN, however, fail the readcond() request with a
ENOSYS, to claim you don’t support readcond(). In that case, pppd
should fall back with a plain read().

A plain read() of what though ? While it sucks that I have to scan for
VFWD, it still means that pppd has to do the same thing, and if it is
going to issue a read for 1 byte, that isn’t going to be any better.

Of cause it won’t do a read for 1 byte, it will still do a read for (I
think)
3042, and your resource manager (since it’s a read) allow to return
whatever you have (1, 4, 16, 64 ?) back. pppd will know it only got
back, say 64 bytes, and scanning the data for VFWD.

I am hoping that devn-fd does something like

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, 0);

then, once it has read the packet data size from the ether header,
do something like

readcond(fd, buf, data->size, data->size, 0, timeout);

I also have select() support so it could select for read, then do a

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, timeout);

and the subsequent read of the packet data as above.

either of these mechanisms should be reasonably efficient, since an
ether header fits easily inside a 64 byte USB packet.

devn-fd is another story. But your method above are based on there
is never ever a byte lose on the hardware, which is not what devn-fd
could do.

So, any clues about what it does (all I have received from it so
far is a readcond for 3042 bytes) ?

If “ahdlc” is enabled, devn-fd will put a packet into an AHDLC frame,
and send it out. The receiver is expect to receive a FULL ahdlc frame
(by setting the VFWD).

Unfortunatly, devn-fd don’t have a fall back (like pppd) to use read()
to achive the same result (scaning VFWD itself).

-xtang

[Rennie_Allen2]

Xiaodan Tang wrote:

Rennie Allen <> rgallen@attbi.com> > wrote in message
news:c2gbo8$99v$> 1@inn.qnx.com> …


Of cause it won’t do a read for 1 byte, it will still do a read for (I
think)
3042, and your resource manager (since it’s a read) allow to return
whatever you have (1, 4, 16, 64 ?) back. pppd will know it only got
back, say 64 bytes, and scanning the data for VFWD.

OK, cool. This will probably help alot then.

devn-fd is another story. But your method above are based on there
is never ever a byte lose on the hardware, which is not what devn-fd
could do.

I’m not sure why you think my method relies on never losing a byte (that’s
what the timeouts are for) but regardless, in my case the hardware never
will lose a byte, since USB is itself a reliable transport.

If “ahdlc” is enabled, devn-fd will put a packet into an AHDLC frame,
and send it out. The receiver is expect to receive a FULL ahdlc frame
(by setting the VFWD).

Ah, so devn-fd should work with my driver the way it is now (haven’t
tried it yet).

Unfortunatly, devn-fd don’t have a fall back (like pppd) to use read()
to achive the same result (scaning VFWD itself).

Well, pppd with large reads (and no VFWD) should be better anyway, since
pppd will strip the ip header if I’m not mistaken, while devn-fd would
still xmit the ip header, as well as add a ethernet header.

Thanks Xiaodan.

Rennie

[Xiaodan_Tang1]

Rennie Allen <rgallen@attbi.com> wrote in message
news:c2hqtc$han$1@inn.qnx.com…

Xiaodan Tang wrote:

If “ahdlc” is enabled, devn-fd will put a packet into an AHDLC frame,
and send it out. The receiver is expect to receive a FULL ahdlc frame
(by setting the VFWD).

Ah, so devn-fd should work with my driver the way it is now (haven’t
tried it yet).

With AHDLC, and with your resmgr support VFWD, then yes

Unfortunatly, devn-fd don’t have a fall back (like pppd) to use read()
to achive the same result (scaning VFWD itself).

Well, pppd with large reads (and no VFWD) should be better anyway, since
pppd will strip the ip header if I’m not mistaken, while devn-fd would
still xmit the ip header, as well as add a ethernet header.

Actually pppd does not strip the ip header, the receiver pppd may need
the IP header to forward the packet. There is VJ compress would
strip/restore
IP/TCP header but this option only exist in 6.3.

-xtang

[Johan_Bjork1]

“Rennie Allen” <rgallen@attbi.com> wrote in message
news:c2gbo8$99v$1@inn.qnx.com…

Xiaodan Tang wrote:
Rennie Allen <> rgallen@attbi.com> > wrote in message
news:c2eb7s$ieh$> 1@inn.qnx.com> …

Hehe, glad you figured it out. It’s pppd setup the VFWD and want to do
a readcond(). You CAN, however, fail the readcond() request with a
ENOSYS, to claim you don’t support readcond(). In that case, pppd
should fall back with a plain read().

A plain read() of what though ? While it sucks that I have to scan for
VFWD, it still means that pppd has to do the same thing, and if it is
going to issue a read for 1 byte, that isn’t going to be any better.

I am hoping that devn-fd does something like

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, 0);

then, once it has read the packet data size from the ether header,
do something like

readcond(fd, buf, data->size, data->size, 0, timeout);

I also have select() support so it could select for read, then do a

readcond(fd, buf, sizeof(eth_hdr),sizeof(eth_hdr), 0, timeout);

and the subsequent read of the packet data as above.

either of these mechanisms should be reasonably efficient, since an
ether header fits easily inside a 64 byte USB packet.

So, any clues about what it does (all I have received from it so
far is a readcond for 3042 bytes) ?

ps: devn-fd is far more painful to test with than ppp, since it
can’t be umounted without taking io-net down, and momentics has
a tizzy if io-net goes away.

How do you mean “has a tizzy”, Developing network drivers you keep taking
io-net up and down all the time with no problems at all (when not testing
transmitting packets, you can even have another io-net running and still be
online surfing ) except XPhoton, which seems to run READY once io-net is
slayed for the first time, kill XPhoton and all is fine though.

Cheers
/Johan
/J

[Rennie_Allen2]

Johan Björk wrote:

“Rennie Allen” <> rgallen@attbi.com> > wrote in message
news:c2gbo8$99v$> 1@inn.qnx.com> …

How do you mean “has a tizzy”, Developing network drivers you keep taking
io-net up and down all the time with no problems at all (when not testing
transmitting packets, you can even have another io-net running and still be
online surfing > > ) except XPhoton, which seems to run READY once io-net is
slayed for the first time, kill XPhoton and all is fine though.

I am referring to eclipse. It sends a whole bunch of threads ready, when
io-net goes AWOL. Could be due to the fact that I have some of my directories
nfs mounted, but I still don’t see why it needs to run ready…

Killing eclipse makes everything fine too, but somehow waiting for 5 minutes
for eclipse to return, just doesn’t cry out “productivity” to me

Rennie

[Rennie_Allen2]

Xiaodan Tang wrote:

Rennie Allen <> rgallen@attbi.com> > wrote in message
news:c2hqtc$han$> 1@inn.qnx.com> …

Actually pppd does not strip the ip header, the receiver pppd may need
the IP header to forward the packet. There is VJ compress would
strip/restore
IP/TCP header but this option only exist in 6.3.

Didn’t QNX 4.20 have VJ header compression (with slip) ? A little strange
to find out that 13 years later its only scheduled for the next version of
ppp

[Chris_McKillop1]

I am referring to eclipse. It sends a whole bunch of threads ready, when
io-net goes AWOL. Could be due to the fact that I have some of my directories
nfs mounted, but I still don’t see why it needs to run ready…

Killing eclipse makes everything fine too, but somehow waiting for 5 minutes
for eclipse to return, just doesn’t cry out “productivity” to me >

Start another instance of io-net. Then existing connections won’t be
broken when you kill off your test instance.

chris

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

[David_Gibbs1]

Chris McKillop <cdm@qnx.com> wrote:

I am referring to eclipse. It sends a whole bunch of threads ready, when
io-net goes AWOL. Could be due to the fact that I have some of my directories
nfs mounted, but I still don’t see why it needs to run ready…

Killing eclipse makes everything fine too, but somehow waiting for 5 minutes
for eclipse to return, just doesn’t cry out “productivity” to me >


Start another instance of io-net. Then existing connections won’t be
broken when you kill off your test instance.

And, you might want to post HOW to do this without name-space clashes
and all that fun stuff.

And, how to tell applications to use the debug version, so you can
actually test your new driver with some data…

-David

David Gibbs
dagibbs@qnx.com

[Chris_McKillop1]

And, you might want to post HOW to do this without name-space clashes
and all that fun stuff.

And, how to tell applications to use the debug version, so you can
actually test your new driver with some data…

Old connections stay connected to the old io-net, new connections go to
the new io-net. Nothing to do besides running a second instance, it
overlays the namespace. I would often do this when I was debugging
drivers. Start inetd, fs-nfs3, etc with the first io-net and then
when the second one started I could start a second inetd for testing.

chris

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

[David_Gibbs1]

Chris McKillop <cdm@qnx.com> wrote:

And, you might want to post HOW to do this without name-space clashes
and all that fun stuff.

And, how to tell applications to use the debug version, so you can
actually test your new driver with some data…


Old connections stay connected to the old io-net, new connections go to
the new io-net. Nothing to do besides running a second instance, it
overlays the namespace. I would often do this when I was debugging
drivers. Start inetd, fs-nfs3, etc with the first io-net and then
when the second one started I could start a second inetd for testing.

Ah, ok. I thought there was some namespace/registered name stuff one
could do with a SOCK or SOCKET environment variable, and a different
registered name.

Hm…new connections go to the new stack…if that’s the one you’re
debugging might not be too pretty…

-David

David Gibbs
dagibbs@qnx.com

[Sean_Boudreau1]

David Gibbs <dagibbs@qnx.com> wrote:

Chris McKillop <> cdm@qnx.com> > wrote:

And, you might want to post HOW to do this without name-space clashes
and all that fun stuff.

And, how to tell applications to use the debug version, so you can
actually test your new driver with some data…


Old connections stay connected to the old io-net, new connections go to
the new io-net. Nothing to do besides running a second instance, it
overlays the namespace. I would often do this when I was debugging
drivers. Start inetd, fs-nfs3, etc with the first io-net and then
when the second one started I could start a second inetd for testing.

Ah, ok. I thought there was some namespace/registered name stuff one
could do with a SOCK or SOCKET environment variable, and a different
registered name.

You can do this as well. Doc’d for 6.3.

io-net -p tcpip prefix=/alt

SOCK=/alt ping 127.1

export SOCK=/alt

netstat -in

…
…
…

Hm…new connections go to the new stack…if that’s the one you’re
debugging might not be too pretty…

-David

David Gibbs
dagibbs@qnx.com