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). But then, if someone has created configuration on a non-existent interface, and later the underlying datalink for that interface is added to the system, how does one activate the latent configuration? E.g., the net-physical script will need something like "ipadm create-interface", or "ipadm init-intfprop <intf>" to create the interface and apply the latent configuration. >> this part, while a neat idea, would need some careful design to be >> consistently available across all the adminstrative levels. Particularly, >> recovering from (or even reporting) badly constructed commands must >> be done with care.. > > I don't understand what you mean with badly constructed. Do you have an > example? e.g., with dladm, we only write out the property configuration to datalink.conf if the attempt to set the property in the kernel succeeds. So syntax/sanity checking is done at least once, before saving the configuration. But even with this model, there's a problem reporting errors during boot, when the driver autoconfigures itself, and sucks down the persisten properties from dlmgmtd- if an error occurs, say, when there's a syntax error for a property in an under-link of an aggregation, error reporting, and recovery from partial configuration is not easy- its not impossible to do, but not always simple either. And bugs like 6674410 & 6662859 also get in the way. --Sowmini _______________________________________________ networking-discuss mailing list [email protected]
