Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
soc:alanshieh [2006/08/11 13:16] ashieh |
soc:alanshieh [2006/08/11 13:31] (current) ashieh |
||
---|---|---|---|
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 ===== |