이 문서는 카드가 어떻게 작동하는가를 조금이라도 더 이해하길 원하거나, 현재 드라이버들을 가지고 놀거나 현재 지원되지 않는 카드의 고유한 드라이버를 만들려고 하는이들에게 매우 유용 할 것이다. 만일 이 카테고리에 빠져들기 싫다면 이 장을 넘어가도 된다.
만일 여러분이 이미 백투백 패킷들을 보내고 받을수 있다면, 선을 통해 더 많은 것을 넣을수는 없다. 모든 현대적인 이더넷 카드는 백투백 패킷들을 받을수 있다. 리눅스의 DP8390 드라이버들 (wd80x3, SMC-Ultra, 3c503, ne2000, 등등)은 백투백 패킷들을 매우 잘 보내고(현재의 인터럽트 대기시간에 의존한다) 3c509와 AT1500 하드웨어는 자동으로 백투백 패킷들을 보내는데 전혀 문 제가 없다.
ISA 버스는 5.3MB/sec (42Mb/sec)의 속도를 가질수 있으며, 10Mbps 이더넷에는 충분해 보인다. 100Mbps 카드들의 경우에는 네트워크 대역폭의 이점을 얻기 위해서는 더 빠른 버스가 필요한 것이 당연하다.
Pro: 어떠한 강제적인 시스템 자원의 사용도 없으며, 아주 조금의 I/O 레지스터를 사용하고, 16M 제한을 가지지 않는다.
Con: 보통 전송률이 가장 느리고, CPU는 항상 기다려야하며, 끼어든 패킷에 대한 접근은 보통 힘들거나 불가능하다.
Pro: 간단하고, programmed I/O 보다 빠르며, 패킷들에 대한 무작위 접근이 허용된다. 어디에서 사용되냐면, 리눅스 드라이버들이 들어온 IP 패킷들이 카드에서 복사되므로 그들의 체크섬을 계 산하고, 그로인해 동급의 PIO 카드에 비해 CPU 점유율이 적어진다.
Con: 메모리 공간을 사용하며 (DOS 사용자들에게는 매우 큰거지만, 리눅스상에서는 특별히 문제 되지 않는다), 그리고 여전히 CPU를 잡아둔다.
Pro: 실제 데이타 전송시에는 CPU 를 놓아준다.
Con: 경계선 상태를 확인하고, 인접한 버퍼들을 재배치하며, DMA 리지스터들을 프로그래밍하여 모든 기술들중에 가장 느리다. 또한 부족한 DMA 채널을 사용하며, 저수준 메모리 버퍼의 정렬을 필요로 한다.
Pro: 데이타 전송중에는 CPU가 자유로우며, 버퍼들과 함께 배열할수 있으며, ISA 버스상에서 잃어버리는 아주 조금이나 아니면 CPU시간을 전혀 필요로하지 않기도 한다. 대부분의 버스 마스 터링 리눅스 드라이버들은 현재 `카피브레이크' 구조를 사용하는데 이것은 카드가 큰 패킷들을 커널 네트워킹 버퍼에 직접 넣는 장소이고, 작은 패킷들은 CPU가 복사함으로서 이후로 진행되는 캐시를 준비하게 한다.
Con: (ISA 버스 카드들에만 해당된다) 카드에는 저수준 메모리 버퍼와 DMA채널이 필요하다. Any bus-master will have problems with other bus-masters that are bus-hogs, such as some primitive SCSI adaptors. A few badly-designed motherboard chipsets have problems with bus-masters. And a reason for not using any type of DMA device is using a 486 processor designed for plug-in replacement of a 386: these processors must flush their cache with each DMA cycle. (This includes the Cx486DLC, Ti486DLC, Cx486SLC, Ti486SLC, etc.)
The only thing that one needs to use an ethernet card with Linux is the appropriate driver. For this, it is essential that the manufacturer will release the technical programming information to the general public without you (or anyone) having to sign your life away. A good guide for the likelihood of getting documentation (or, if you aren't writing code, the likelihood that someone else will write that driver you really, really need) is the availability of the Crynwr (nee Clarkson) packet driver. Russ Nelson runs this operation, and has been very helpful in supporting the development of drivers for Linux. Net-surfers can try this URL to look up Russ' software.
Given the documentation, you can write a driver for your card and use it for Linux (at least in theory). Keep in mind that some old hardware that was designed for XT type machines will not function very well in a multitasking environment such as Linux. Use of these will lead to major problems if your network sees a reasonable amount of traffic.
Most cards come with drivers for MS-DOS interfaces such as NDIS and ODI, but these are useless for Linux. Many people have suggested directly linking them in or automatic translation, but this is nearly impossible. The MS-DOS drivers expect to be in 16 bit mode and hook into `software interrupts', both incompatible with the Linux kernel. This incompatibility is actually a feature, as some Linux drivers are considerably better than their MS-DOS counterparts. The `8390' series drivers, for instance, use ping-pong transmit buffers, which are only now being introduced in the MS-DOS world.
(Ping-pong Tx buffers means using at least 2 max-size packet buffers for Tx packets. One is loaded while the card is transmitting the other. The second is then sent as soon as the first finished, and so on. In this way, most cards are able to continuously send back-to-back packets onto the wire.)
OK. So you have decided that you want to write a driver for the Foobar Ethernet card, as you have the programming information, and it hasn't been done yet. (...these are the two main requirements ;-) You should start with the skeleton network driver that is provided with the Linux kernel source tree. It can be found in the file /usr/src/linux/drivers/net/skeleton.c in all recent kernels. Also have a look at the Kernel Hackers Guide, at the following URL: KHG
Here are some notes on the functions that you would have to write if creating a new driver. Reading this in conjunction with the above skeleton driver may help clear things up.
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. Initial writing to I/O ports in a probe is not good as it may kill another device. Some device initialization is usually done here (allocating I/O space, IRQs,filling in the dev->??? fields etc.) You need to know what io ports/mem the card can be configured to, how to enable shared memory (if used) and how to select/enable interrupt generation, etc.
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. You need to know any relevant interrupt status bits so that you can act accordingly.
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. You need to
know how to bundle the data and how to get it onto the
card (shared memory copy, PIO transfer, DMA?) and in
the right place on the card. Then you need to know
how to tell the card to send the data down the wire, and
(possibly) post an interrupt when done.
When the hardware can't accept additional packets it should set
the dev->tbusy flag. When additional room is available, usually
during a transmit-complete interrupt, dev->tbusy should be cleared
and the higher levels informed with mark_bh(INET_BH).
Called by the kernel 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). You need to know how to enable interrupt generation upon Rx of data, how to check any relevant Rx status bits, and how to get that data off the card (again sh mem, PIO, DMA, etc.)
linked to dev->open and called by the networking layers
when somebody does ifconfig eth0 up - this
puts the device on line and enables it for Rx/Tx of
data. Any special initialization incantations that were
not done in the probe sequence (enabling IRQ generation, etc.)
would go in here.
This puts the card in a sane state when someone
does ifconfig eth0 down.
It should free the IRQs and DMA channels if the hardware permits,
and turn off anything that will save power (like the transceiver).
Things like a reset function, so that if things go south, the driver can try resetting the card as a last ditch effort. Usually done when a Tx times out or similar. Also a function to read the statistics registers of the card if so equipped.
If you are interested in working on drivers for 3Com cards, you can get technical documentation from 3Com. Cameron has been kind enough to tell us how to go about it below:
3Com's Ethernet Adapters are documented for driver writers in our `Technical References' (TRs). These manuals describe the programmer interfaces to the boards but they don't talk about the diagnostics, installation programs, etc that end users can see.
The Network Adapter Division marketing department has the TRs to give away. To keep this program efficient, we centralized it in a thing called `CardFacts.' CardFacts is an automated phone system. You call it with a touch-tone phone and it faxes you stuff. To get a TR, call CardFacts at 408-727-7021. Ask it for Developer's Order Form, document number 9070. Have your fax number ready when you call. Fill out the order form and fax it to 408-764-5004. Manuals are shipped by Federal Express 2nd Day Service.
There are people here who think we are too free with the manuals, and they are looking for evidence that the system is too expensive, or takes too much time and effort. So far, 3Com customers have been really good about this, and there's no problem with the level of requests we've been getting. We need your continued cooperation and restraint to keep it that way.
The AMD LANCE (Local Area Network Controller for Ethernet) was the original offering, and has since been replaced by the `PCnet-ISA' chip, otherwise known as the 79C960. Note that the name `LANCE' has stuck, and some people will refer to the new chip by the old name. Dave Roberts of the Network Products Division of AMD was kind enough to contribute the following information regarding this chip:
`Functionally, it is equivalent to a NE1500. The register set is identical to the old LANCE with the 1500/2100 architecture additions. Older 1500/2100 drivers will work on the PCnet-ISA. The NE1500 and NE2100 architecture is basically the same. Initially Novell called it the 2100, but then tried to distinguish between coax and 10BASE-T cards. Anything that was 10BASE-T only was to be numbered in the 1500 range. That's the only difference.
Many companies offer PCnet-ISA based products, including HP, Racal-Datacom, Allied Telesis, Boca Research, Kingston Technology, etc. The cards are basically the same except that some manufacturers have added `jumperless' features that allow the card to be configured in software. Most have not. AMD offers a standard design package for a card that uses the PCnet-ISA and many manufacturers use our design without change. What this means is that anybody who wants to write drivers for most PCnet-ISA based cards can just get the data-sheet from AMD. Call our literature distribution center at (800)222-9323 and ask for the Am79C960, PCnet-ISA data sheet. It's free.
A quick way to understand whether the card is a `stock' card is to just look at it. If it's stock, it should just have one large chip on it, a crystal, a small IEEE address PROM, possibly a socket for a boot ROM, and a connector (1, 2, or 3, depending on the media options offered). Note that if it's a coax card, it will have some transceiver stuff built onto it as well, but that should be near the connector and away from the PCnet-ISA.'
A note to would-be card hackers is that different LANCE implementations do `restart' in different ways. Some pick up where they left off in the ring, and others start right from the beginning of the ring, as if just initialised.
Another one of the things Donald has worked on is implementing multicast and promiscuous mode hooks. All of the released (i.e. not ALPHA) ISA drivers now support promiscuous mode.
Donald writes: `I'll start by discussing promiscuous mode, which is conceptually easy to implement. For most hardware you only have to set a register bit, and from then on you get every packet on the wire. Well, it's almost that easy; for some hardware you have to shut the board (potentially dropping a few packet), reconfigure it, and then re-enable the ethercard. OK, so that's easy, so I'll move on something that's not quite so obvious: Multicast. It can be done two ways:
I guess I should list what a few ethercards/chips provide:
Chip/card Promiscuous Multicast filter
----------------------------------------
Seeq8001/3c501 Yes Binary filter (1)
3Com/3c509 Yes Binary filter (1)
8390 Yes Autodin II six bit hash (2) (3)
LANCE Yes Autodin II six bit hash (2) (3)
i82586 Yes Hidden Autodin II six bit hash (2) (4)
Note that none of these chips do perfect filtering, and we still need a middle-level module to do the final filtering. Also note that in every case we must keep a complete list of accepted multicast addresses to recompute the hash table when it changes.
The general idea of the developers is that the BPF functionality should not be provided by the kernel, but should be in a (hopefully little-used) compatibility library.
For those not in the know: BPF (the Berkeley Packet Filter) is an mechanism for specifying to the kernel networking layers what packets you are interested in. It's implemented as a specialized stack language interpreter built into a low level of the networking code. An application passes a program written in this language to the kernel, and the kernel runs the program on each incoming packet. If the kernel has multiple BPF applications, each program is run on each packet.
The problem is that it's difficult to deduce what kind of packets the application is really interested in from the packet filter program, so the general solution is to always run the filter. Imagine a program that registers a BPF program to pick up a low data-rate stream sent to a multicast address. Most ethernet cards have a hardware multicast address filter implemented as a 64 entry hash table that ignores most unwanted multicast packets, so the capability exists to make this a very inexpensive operation. But with the BPF the kernel must switch the interface to promiscuous mode, receive _all_ packets, and run them through this filter. This is work, BTW, that's very difficult to account back to the process requesting the packets.