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/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:29 EST