Re: Univeral Protocol Driver (using UNDI) in Linux

[Donald Becker <becker@scyld.com>]

On Tue, 8 Aug 2006, Alan Shieh wrote:

> With help from the Etherboot Project, I've recently implemented such a 
> driver for Etherboot 5.4. It currently supports PIO NICs (e.g. cards 
> that use in*/out* to interface with CPU). It's currently available in a 
> branch, and will be merged into the trunk by the Etherboot project. It 
> works reliably with QEMU + PXELINUX, with the virtual ne2k-pci NIC.
> 
> Barring unforseen issues, I should get MMIO to work soon; target 
> platform would be pcnet32 or e1000 on VMware, booted with PXELINUX.

Addressing a very narrow terminology issue:

I think that there a misuse of terms here.  PIO, or Programmed I/O, is 
data transfer mode where the CPU explicitly passes data to and from a 
device through a single register location.

The term is unrelated to the device being addressed in I/O or memory 
space.  On the x86, hardware devices were usually in the I/O address space 
and there are special "string" I/O instructions, so PIO and I/O space were 
usually paired.  But processors without I/O instructions could still do 
PIO transfers.

Memory Mapped I/O, MMIO, is putting the device registers in memory space.  
In the past it specifically meant sharing memory on the device e.g. when 
the packet buffer memory on a WD8013 NIC was jumpered into the ISA address 
space below 1MB.  The CPU still controls the data transfer, generating a 
write for each word transfered.  But the address changed with each write, 
just like a memcpy.

Today "MMIO" is sometimes misused to mean simply using a PCI memory 
mapping rather than a PCI I/O space mapping.  PCI actually has three 
address spaces: memory, I/O and config spaces.  Many devices allow 
accessing the operational registers either through I/O or memory spaces.

Both PIO and MMIO are obsolescent.  You'll still find it in legacy 
interfaces, such as IDE disk controllers where it is only used during boot 
or when running DOS. Instead bulk data is moved using bus master 
transfers, where the device itself generates read or write 
bus transactions.

Specifically, you won't find PIO or MMIO on any current NIC.  They only 
existed on a few early PCI NICs, circa 1995,  where an ISA design was 
reworked.  

So what does all of this have to with UNDI (and, not coincidentally,
virtualization)?  There are a bunch of problems with using UNDI drivers,
but we only need one unsolvable one to make it a doomed effort.  It's a
big challenge to limit, control and remap how the UNDI driver code talks
to the hardware.  That seems to be focus above -- just dealing with how to
control access to the device registers.  But even if we do that correctly
, the driver is still setting up the NIC to be a bus master.  The device
hardware will be reading and writing directly to memory, and the driver
has to make a bunch of assumptions when calculating those addresses.
 
> ( An even easier way would be to axe the manufacturer's stack and use 
> Etherboot instead )

People are hoping to magically get driver support for all hardware 
without writing drivers.  If it were as easy as writing a Linux-to-UNDI 
shim, that shim would have been written long ago.  UNDI doesn't come 
close to being an OS-independent driver interface, even if you are willing 
to accept the big performance hit.


-- 
Donald Becker				becker@scyld.com
Scyld Software	 			Scyld Beowulf cluster systems
914 Bay Ridge Road, Suite 220		www.scyld.com
Annapolis MD 21403			410-990-9993

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/