> I don't know anything about this topic. The kernel source
> includes a skeleton.c file that can get you started.
> Someone has promised to write this section, so check back
> sometime...
Hrrm, who was that? (just curious...)
Somebody asked me about a year or so ago as to what the basics
of a net driver would look like. I haven't seen Alan's article
in linux journal, so this may be useless in comparison.
Regardless, here it is anyway.
Paul.
------------------------------
1) Probe:
called at boot to check for existence of card. Best if it
can check un-obtrsively by reading from memory, etc. Can
also read from i/o ports. Writing to i/o ports in a probe
is *not* allowed as it may kill another device.
Some device initialization is usually done here (allocating
i/o space, IRQs,filling in the dev->??? fields etc.)
2) Interrupt handler:
Called by the kernel when the card posts an interrupt.
This has the job of determining why the card posted
an interrupt, and acting accordingly. Usual interrupt
conditions are data to be rec'd, transmit completed,
error conditions being reported.
3) Transmit function
Linked to dev->hard_start_xmit() and is called by the
kernel when there is some data that the kernel wants
to put out over the device. This puts the data onto
the card and triggers the transmit.
4) Receive function
Called by the interrupt handler when the card reports
that there is data on the card. It pulls the data off
the card, packages it into a sk_buff and lets the
kernel know the data is there for it by doing a
netif_rx(sk_buff)
5) Open function
linked to dev->open and called by the networking layers
when somebody does "ifconfig <device_name> up" -- this
puts the device on line and enables it for Rx/Tx of
data.
Someday, perhaps I will have the time to write a proper
document on the subject.... Naaaaahhhhhh.
|
Re: Network Device Drivers by Neal Tucker
Transmit function by Joerg Schorr
Re: Transmit function by Paul Gortmaker
Skbuff by Joerg Schorr