[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: submit patch for udhcpc - addition of Option 43
From:       Christopher Barry <christopher.barry () rackwareinc ! com>
Date:       2010-03-23 23:47:56
Message-ID: 1269388076.3556.38.camel () vector ! infinux ! org
[Download RAW message or body]

On Mon, 2010-03-22 at 19:50 +0100, Denys Vlasenko wrote:
> On Mon, Mar 22, 2010 at 7:31 PM, Krebs, Steven <steven.krebs@intel.com> wrote:
> > On Mon, Mar 22, 2010 at 12:14 PM, Denys Vlasenko wrote:
> > > Something like -x "vendorinfo:suboption=value" might work.
> > > ...
> > > Several -x options should accumulate.
> > 
> > Will getopt32() support multiple instances of a single option? (-x) example:
> > 
> > udhcpc -i eth1 -s etc/udhcpc.script -V "OpenCable2.1" -x \
> > "vendorspecific:sub2=ESTB" -x "fqdn:string" -x "vendorspecific:sub4=$SERIAL_NO"
> 
> Yes. For example, take a look at coreutils/env.c, how it handles
> multiple -u options.
> 
> 
> > > Here "vendorinfo" is the DHCP option name.
> > 
> > Also, you indicate you like the string vendorinfo, however since the spec defines \
> > it as vendor specific, I would rather keep the string closer to the spec with \
> > something like vendor_specific or vendorspecific.
> 
> This is such a small detail it can be discussed later, when the hard
> part is done.
> 
> > > udhcpd already does something like that
> > > in order to handle udhcpd.conf which can contain
> > > directives like:
> > > 
> > > opt     dns     192.168.10.2 192.168.10.10
> > > option  subnet  255.255.255.0
> > > opt     router  192.168.10.2
> > > opt     wins    192.168.10.10
> > > option  dns     129.219.13.81   # appended to above DNS servers for a total of \
> > > 3 option  domain  local
> > > option  lease   864000          # default: 10 days
> > 
> > Also, since udhcpd uses a config file for multiple options, why not allow udhcpc \
> > to use a similar config file?  Example: 
> > /etc/udhcpc.conf
> > opt     vendorclass     OpenCable2.1
> > option  vendorspecific  2=ESTB 3=ECM:ESTB 4=SN00000001
> 
> How would you pass spaces in suboption values if you need to?
> 
> > opt     script          /etc/udhcpc.script
> > 
> > Where the 2nd parameter could match the udhcpc_longopts[] name.
> 
> I don't know why, but I am perfectly happy with udhcpc having
> only a command-line interface.

As a user, from my perspective, having a single, simple conf file that
always gets read specifying the desired options to request (or set)
would be the optimum solution. Using -c <config_file> would allow using
any correctly formatted file for this purpose.

not to remove certain basic commandline options, of course, but having
it dynamically extensible via a config file would be great.

# names for option numbers
my_option      = 104
another_option = 66

# option name            option value      option type
set my_option            foo               str
req another_option       -                 array

the client itself would set the variables that are 'set', and once the
server responds, the client would simply set into the environment the
requested values, just as it does now.

echo ${my_option}
foo
echo ${another_option[@]}
192.168.1.4 192.168.2.4

Ideally, even made up local options could be requested and or set
easily. I realize 'type' may be an issue with this, but possible a type
column could be used for this? str|array|bin maybe? array would not be
available with sh, but it would be nice to have when bash is available.

Just a thought :)
-C




_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]