Alan Maguire writes: > > There's more to it than that. The /sbin/dhcpagent interface itself is > > documented and the "-a" command line flag (used for the, in my > > opinion, highly questionable) "adopt" functionality needs to be > > reimplemented in these terms. In other words, "adopt" needs to become > > a new libdhcpagent IPC mechanism, and /sbin/dhcpagent itself needs to > > enable the service and call the IPC to deliver the command line flags. > > ah yes, just noticed this - maybe the way to handle this would be to represent > commandline arguments as properties (as was done with the routing daemons > when they were converted). so we'd have a dhcp application property group > with properties for each commandline option. this would fit well with Visual > Panels > too, since users could configure dhcpagent as required via those properties.
Though that might work, I don't think that's really the right translation of the mechanism. I think translating it into an IPC using the existing signaling mechanism is a *lot* more obvious. The debug options, though, are probably more natural as properties. > so invoking dhcpagent with "-a" would be equivalent to setting the > "dhcp/adopt_interface" property to true in the dhcp-agent instance and > enabling. > that takes care of the /sbin/dhcpagent -a call in net-physical. the only > problem > is we'd then need to explicitly set the dhcp/adopt_interface property to false > prior to the enable of dhcpagent done in libdhcpagent to match current > behaviour > (all assuming of course we want to preserve the "adopt" functionality). Yes. Ick. And for completeness, you'd probably have to handle the race condition between setting the property and then starting up the daemon. I think the IPC mechanism (which keeps the interface name and command together in a transaction) is better. It think it's better still if only the bits that need to know about adoption actually know about it. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
