On 04/11/09 07:09 AM, [email protected] 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
_______________________________________________
networking-discuss mailing list
[email protected]
