This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
soc:alanshieh [2006/08/11 13:16]
soc:alanshieh [2006/08/11 13:31] (current)
Line 1: Line 1:
 ====== Alan Shieh, Linux UNDI Driver ====== ====== Alan Shieh, Linux UNDI Driver ======
 +===== Comparing a UNDI driver to server-side initrd selection =====
 +It is possible to achieve the same effect as an UNDI driver with other approaches, such as loading all possible drivers into an initrd, or selecting an initrd based on MAC address, thus allowing Linux to load the right module. Such a design of this is much more conservative,​ as it relies on driver code that has been used by a larger population
 +There are some disadvantages with each approach. Having a larger initrd may increase the booting time or RAM requirements. Selecting initrd based on MACs requires a MAC=>NIC database. This may need to be collected manually, or make assumptions based on MAC=>​Manufacturer mappings. For instance, one could provide all Intel drivers for all NICs with a MAC that is assigned to Intel.
 +UNDI has its advantages and disadvantages. New deployments that install Etherboot stacks on supported NICs will automatically support the UNDI driver, without configuring any other software. A boot process that uses the UNDI driver can use arbitrary userspace / kernel code to talk to network and figure out how to load the right drivers for a particular machine.
 +Though the UNDI driver is about an order of magnitude slower than the Linux driver, it can still download most modules in <1s on an emulated NE2K-PCI.
 ===== Deliverables and Timeline ===== ===== Deliverables and Timeline =====

QR Code
QR Code soc:alanshieh (generated for current page)