On Mon, Mar 22, 2010 at 7:31 PM, Krebs, Steven <[email protected]> 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. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
