Re: [Etherboot-developers] changes checked into CVS

[<ke...@us...>]

>Guess I'll have to rework dhcpd.conf so that it can cope with both
>versions.  This is doable but it's just incredibly irritating: the text
>version was discussed on the mailing list, was implemented by me without
>any serious objections, has remained unaltered for the past month and a
>half, made it into RC1 and then gets changed at the last minute.  I'd have
>appreciated it if you'd warned that you were planning this change.

I'm sorry about that. Due to lack of time on my part I hadn't actually
looked at your code before I released RC1. I was under the impression
that the binary representation had carried the day.

There are reasons why the binary representation is better. If you do man
dhcp-eval you will find functions for extracting integer sized fields
from the packet. There are no functions for going from text to integer.
Essentially DHCP data IS binary, and it's simply unthinking prejudice to
insist on human readability. There are no humans to read the request
packets and even if you used tcpdump you would pipe it to dhcpdump for
decoding.

With the binary conversion function you can write range tests to say
include 3com NICs from 0x9050 to 0x9060. Such a test is very cumbersome
to write for text fields. Straight equality tests can simply do test
against

	1:10:d7:90:50

as compared to

	"PCI:10d7:9050"

so that's equally easy.

Another reason is the text representation has redundancy.  Because you
chose %hx, it's lowercase but I expect someone would in the future try
to write "PCI:10D7:9050" and wonder why it doesn't work, and then we
would have to have an FAQ. With colon separated hex, it doesn't matter,
it's binary underneath.