On 04/11/09 07:09 AM, Sowmini.Varadhan at Sun.COM wrote: > On (04/10/09 21:24), Erik Nordmark wrote: >>>> And for consistency reasons, since the system can have properties for >>>> interfaces that have disappeared, it probably makes sense to >>>> optionally allow the creation of properties for interfaces that does >>>> not (yet) exist, but relying on a force flag to avoid a typo in the >>>> name of the IP interface being interpreted as a reference to a >>>> non-existing interface. For example: >>>> # ipadm set-prop -p mtu=1400 -m ip bge1 >>>> dladm: interface "bge1" does not exist; use -F to set property >>>> for non-existent interfaces >>>> # ipadm set-prop -F -p mtu=1400 -m ip bge1 >>>> >>>> >>>> If that general approach is sensible for ipadm properties, it >>>> probably also makes sense for IP address management, and it might >>>> make sense to apply it to dladm as well. > > Then again, thinking about this in the context of the other design-review > discussion (around handing dhcp/static/autoconf addresses) brought up > a question: even though we have an ipadm_create_interface() that > consolidates all the plumbing logic, we are proposing to discard > the '/sbin/ipadm create-interface', and instead make the interface > plumbing to be implicit in addr-creation (be it by dhcp/static/whatever).
I don't see the problem with this? The push to make executables call a single library function for each "action" does not fit any solid requirement, rather just a general desire to make things "easier" for applications, as opposed to the complexity of using STREAMS to create & configure a NIC. I don't see the problem with ipadm calling half a dozen or so library functions, should it need to, instead of one that has been super-sized to be the swiss-army-knife create function. Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/brussels-dev/attachments/20090415/4dde7237/attachment.html>
