We're also looking at producing some more in-depth documents on io-pkt
driver development over the next couple of months. 
	Robert.

-----Original Message-----
From: Sean Boudreau [mailto:community-noreply@qnx.com] 
Sent: Friday, December 19, 2008 10:09 AM
To: drivers-networking
Subject: Re: IO-PKT Network Drivers Information

On Fri, Dec 19, 2008 at 02:16:18AM -0500, sathish kumar wrote:
> Hi All,
> 
> Where can i find document/material for writing network device drivers
for IO-PKT. The sam.c and native_drvr.txt doesnt give much detail. Could
someone refer me full detailed document on writing network driver in
IO-PKT framework.

Other than the two documents you mentioned there's sys/dev/doc which
pertains to porting BSD based drivers.  The definitive doc is the
source.  If you post questions we can look into adding to what's
currently available.

-seanb

_______________________________________________
Networking Drivers
http://community.qnx.com/sf/go/post19044

When I first starting writing/porting driver for io-pkt
I found the sample driver to quite clearly show the 
interface to the io-pkt infrastructure.

I think Rob is working on a "how-to" driver doc for
io-pkt .... here's the 100,000 foot view:

1) initialization

io-pkt has a two phase initialization: there is
the XXX_attach() routine which is called once,
for each hardware instance.  The _attach routine
should allocate all the resources that the driver
will require.  The second phase is the XXX_init()
routine, which initializes the hardware and the
memory resources, for operation.  The _init 
function may be called over and over again - 
an important detail

2) transmit

In addition to the _attach and _init callbacks,
you will register a XXX_start callback with
io-pkt, which io-pkt calls when there are packets
for you to transmit.  Assuming that you have the
hardware resources to do so, you pull the packets
off the queue, and load them into the hardware.

3) receive

You don't create a thread in an io-pkt driver - 
again, you register your interrupt with io-pkt,
and it calls you when it fires.  Then, you call
your own handler which looks at the source of
interrupt, and usually drains the packets out
of the hardware and passes them up to io-pkt

4) phy link monitoring

Most hardware does not have a reliable link
state change interrupt, so you usually will
end up periodically polling the PHY to see
if the link state has changed.  The driver
should use the timer callout feature to arm
this.

5) devctl

The driver can choose to handle (or not)
various devctls.  There is a generic ethernet
devctl handler - usually at the bottom - which
is worth peeking at the source to.  Mostly what
you have to worry about here is support for multicast
receive.

6) shutdown

There is another XXX_stop() callback, which
io-net can call.  Just as importantly, the
driver should register another callback with
the shutdownhook_establish() mechanism to ensure
that the hardware is quiesced during abnormal
shutdown of io-pkt (eg sigsegv).

All of the above is off the top of my head.  Again,
I think Rob is working on a doc, and I really suggest
looking at the source.

When I am looking at writing a driver, I generally
choose a driver which is the most similar (eg PCI?)
and use it as a starting point.

Hope this helps,

--
aboyd