Re: [Etherboot-developers] DHCP option 175

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

Christoph Plattner <chr...@al...> writes:

> In my opinion, ASCII text is always preferred. For DHCPD maintainence
> binary data is not a good idea ! And the byte space is definitive not
> critical in this point (3 or 8 bytes ....)

Given that we have a maximum of 1500 bytes in the DHCP packet, size
matters a lot.
 
> But is the whole stuff really a good idea ?
> Is it important to know the interface on the client side ?
> 
> Normally an admin should know the components, ...
> On the other hand, PCs are quickly exchanged ...
> 
> But should the loaded image not independent of the NIC ?

In general this doesn't work.  If you have a 4M machine you
cannot load a generic kernel.  So knowing both the NIC that
needs to be supported and how much ram is in the box allows
something automatic to build an image, which can load and
tell you everything else that is in the box.

> A Linux kenrel for example should have all needed NIC
> drivers compiled in. The same is for GRUB (after all drivers
> are in the well state, that they do not block in probing
> the NICs).

A generic kernel is 10M try that on a 4M machine.

> The string (option 175) must be very clear and simple,
> and in my opinion TEXT.
> Using PCI ID is perhaps not the best idea ! Perhaps it is a
> better idea to give "keywords" at boot ROM compile time,
> which is passed as tag 175.
> 
> Example: 
> I have a new PC with onboard 3COM another with onboard i82559
> and one with a classic rtl8139 NIC inserted. Then I have to 
> build the 3 boot ROMs, like
> 
> make bin32/3c900.rom KEY175="NEWPC_TYPE_1"
> make bin32/eepro100.rom KEY175="NEWPC_TYPE_2"
> make bin32/rtl8139.rom KEY175="OLDPC_TYPE_1"
> 
> Or in another way.
> (Perhaps we take another build call so that an admin can build
> up and maintain his classes of boot ROMs).

There is probably a decent argument for passing a motherboard id.
However before we start compiling this stuff in let's see how
far we can get with generic code that everyone can use.

Right now a loaded image can pass this information back, and you can
track it by mac address.   The motherboard information is something
you can fairly reliably extract from the DMI tables.  So hard coding
it a build time is probably something we don't want to attack just
yet.

Eric