Messages in this thread | | | From | "Stuart Summerville (Deimus)" <> | Subject | Need help with network device driver development | Date | Mon, 24 Jan 2000 02:06:23 +1100 |
| |
Hi there,
I'm toying with the idea of writing (hacking actually..) a psuedo network device driver that doesn't actually interface to nic hardware, but uses a custom packet transmision system. eg. I would have an eth-x interface connected to the psuedo-nic module on one machine, which is connected (by the custom comms system) to an eth-x interface on another machine (possibly the same one).
I've browsed the source for several net drivers (3com, ne, re100, and loopback) and the skeleton driver and have some idea as to whats involved. The "Network buffers & memory management" article from LinuxJournal (http://www2.linuxjournal.com/lj-issues/issue30/1312.html) proved very informative, but I still have some questions:
1) the loopback driver source defines that device as being type ARPHRD_LOOPBACK. The would seem to inform the kernel that the device will be different to normal nic drivers, such as that there will be no interrupt mechanism (should it? I guess there's no rx function required) employed by the driver. My driver needs such distinctions made also (being totally software driven), so how do I find out which ARP_HARDWARE type best matches the requirements of my driver?
Yes, the source is all there, but I'd prefer to read existing literature (or have someone who's "been there, done that" tell me) before diving into the source.
2) How does one debug the way that the kernel brings these modules and interfaces to life? With a hacked version of one of the above drivers properly configured (ie. alias added to /etc/conf.modules, the module "installed" in /lib/mod... & eth if added via linuxconf) all I see when the kernel (RH 6.1) tries to bring up that eth interface on reboot is something like "Bringing up ethx, delayed ethx init..." indicating that something went wrong. The corresponding kernel log (as recorded by dmesg, or seen in /var/log/messages is loaded with insmod) shows test log messages from the start of my driver. No, the fact that the hardware for that driver wasn't present shouldn't matter - I've forced the return of init_module to be 0. Obviously something deeper into the nic probing (or even further) is broken.
What I really need/want is to see more info from the kernel about why it decided to delay init of that eth interface.
3) If these network device drivers must operate in an interrupt driven mode (I'd really rather have the kernel (or ip stack...) poll my driver for received data), can you suggest a way of generating a software interrupt to do this? Can I generate a timer interrupt for my task to prompt the polling of rx'd data, or should I run my custom comms system as a separate task in a polled fashion, which then interrupts the driver for handling of the received data?
4) Any advice about juicy books that might cover this? Any other web pages that elaborate further? I couldn't find anything on the LDP development pages & others....
Thanks, sTu.
---------------------------------------------- Stuart Summerville Home: stus@deimus.com.au Work: stuart.summerville@icpdd.neca.nec.com.au ----------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |