> 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. |