Re: [Etherboot-developers] DHCP option 175

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On 21 May 2002, Eric W. Biederman wrote:
> > > I have just committed some very small (8 lines total) changes to
> > > etherboot.h, nic.h, config.c, main.c.  Etherboot will now send the NIC
> > > driver name (e.g. "RTL8139") as vendor option 175 in the DHCPREQUEST
> > > packet.
> > > The idea behind this is that the DHCP server can use the contents of this
> > > option field to determine the value of the "filename" in the DHCPACK.  In
> > > this way, Etherboot can be directed to automatically download an
> > > appropriate kernel+initrd image.  The dhcpd.conf file could contain, for
> > > example:
> > > <snip>
> > Request.
> > Can we change this to return the PCI vendor id and device id's.  This
> > makes changes in etherboot transparent to configurations.
> > Something like:
> > "PCI:8086:1229" for an Intel NIC
> > "PCI:10b7:9805" for a 3COM NIC
> > For PNPISA devices there is a similiar string we can use.  And for
> > straight ISA we might want to just use the vendor and part number.
> > Especially as there aren't 1-1 mappings between etherboot and foobar.
> 
> This change would make it significantly harder to maintain a DHCP server.
> If Etherboot sends the driver name then the DHCP server configuration only
> needs to know about the 36 Etherboot drivers.  If Etherboot sends the
> vendor and device IDs then the DHCP server configuration needs to know
> about the 112 different cards currently in the Etherboot database.
> Additionally, new card definitions are likely to be added a lot more
> frequently than new drivers(?)

But the process could be fully automated by looking at the etherboot
database, and the kernel module database (/lib/modules/xxx/pcimap).
Both of which are list the vendor id, and device id of the card.   So
once setup the worst you will have to do is rerun a script, that
accomplishes the mapping.  

This has the advantage that it will work on across multiple versions
of etherboot.  Even when support for a card moves in and out of the
tulip driver.

It is completely independent of etherboot in the setup side.  You can
build configuration for every kernel supported network card, without
even looking at etherboot.

It doesn't export unimportant details from etherboot.  Making
etherboot easier to maintain.  You can change card support in a driver
without worring if it will mess up your dhcp configuration.

It should take a handle of fewer bytes to implement.

> If there is a better way to achieve this than sending the Etherboot driver
> name, please let me know!

So in summary I think the PCIID->kernel module mapping is much more
of a constant setup situation than sending etherboot driver names.  
In particular you don't even have care about what etherboot will
support you just have to worry about what you can support.

Eric