On Wed, Oct 20, 2010 at 5:48 PM, Sam Liddicott <[email protected]> wrote: > On 20/10/10 15:18, Denys Vlasenko wrote: > On Wed, Oct 20, 2010 at 4:03 PM, Sam Liddicott <[email protected]> wrote: > > I don't fight your proposal but I don't offer a patch to implement it either. > I don't know if anyone else does. > > I already did it in git. > > I note that you don't propose getting rid of -V or -H. > > I do think about getting rid of -V, -H and -r. -x covers them too. > > For me, -c is quite normal, I just needed to specify the hwtype of 0. > The RFC you quoted stated "A hardware type of 0 (zero) > should be used when the value field contains an identifier > other than a hardware address (e.g. a fully qualified domain name)." > > My read of the RFC is that client ID can be *any binary data*. An ASCIZ string > is not suited for that: for one, how would you include a zero byte in a > string? > Therefore -c CLIENTID is a crippled format from the start, it allows only > *some* > client IDs (namely, string ones), not any possible ID. > > Adding *another* option to fix -c seems strange: it makes more sense > to just fix -c. > > I'd agree if "fix" didn't mean "snipped" as it does in the animal world. > Fixing -c by removing it moves udhcpc closer to netcat and socat than I like.
On the other hand, there are ~255 DHCP options. Adding a command-line option for many of them will exhaust alphabet space for udhcpc -<LETTER>. We already have -r, -h/-H, -V and -c, and we'd have more by now had I not NAKed several patches in the past which tried to add more. Instead, now we have generic and extendable -x option, which handled the needs of those NAKed patches, and it can handle any imaginable weird option format we may need later on. Client-id is just one of them. I understand that quickly adding an option to fix your problem sounds like a quick and workable fix for you, but it leads to command line option maintenance nightmare in the long run. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
