On Fri, Mar 18, 2011 at 4:05 PM, Nigel Hathaway <[email protected]> wrote: > Although udhcpc has a mechanism for specifying any arbitrary options to > be supplied with the request to the server, there appears to be no means > of having arbitrary response options passed on to the script. > > Currently, the code goes through each supported option, searching the > options supplied from the server to see if each is there. If it is, it > processes it accordingly, usually resulting in an environment variable > that is passed to the script. > > I propose a change to make the search go the other way round. The code > would go through each option provide by the server. If it is found to be > one of the supported ones, then the appropriate action is taken. If not, > a default action is taken which is to create a generalised environment > variable for passing to the script, as described below. > > First question: this will change the order in which options are > processed. Will this make a difference?
This behavioral change is ok. > The obvious format for the environment variable is name: "opt-125" (for > excmple), value "123456789ABC" i.e. an ascii-hex-encoded binary string. Looks like a good idea. > The trouble with hex-encoded binary is that script gymnastics is > required to compose and decompose these. On the other hand, if you have > some sort of picture string (scanf/printf) to do this, you hit serious > limits as some options have complex hierarchical data. Such data would > really need some sort of ASN.1-style decomposition which is much too > complex for this context. Yes, I think we should not go there. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
