> 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. 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). > I agree that it's all doable, but it's fairly far afield of what I'm > trying to accomplish here, and I feel like I've already done quite > enough. :-/ absolutely! it's very much a folllow-on RFE. > I think that the system is still quite usable without fixing that -- the > cases where > in.ndpd actually does have to start up dhcpagent are few and where > ndpd is restarted are fewer still -- but I agree that it's not at all > right. yep - in practice i suspect the only time the ndp service will be stopped is when the system is shutting down and its dependencies are no longer sastisfied, so this likely won't be problematic. alan This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
