Robert Craig
|
RE: IO-PKT Network Drivers Information
|
Robert Craig
12/19/2008 10:15 AM
post19047
|
RE: IO-PKT Network Drivers Information
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
|
|
|
Andrew Boyd(deleted)
|
RE: IO-PKT Network Drivers Information
|
Andrew Boyd(deleted)
12/19/2008 10:24 AM
post19049
|
RE: IO-PKT Network Drivers Information
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
|
|
|