> So all of this is being unified now under the newly proposed 
> datalink.conf, right? 

I would think so, except some security sensitive configuration (which is 
described int the design doc.)

> It seems that there is an opportunity to use SMF 
> as part of introducing this unified data-link properties repository. Are 
> you expecting that this file will be used for new classes of data-links 
> coming down the road as well?
> 
I hope so.

> All of the above :-)
> 
> There's of course the implementation aspect, where SMF can help manage 
> these properties. I.e. does it make sense to provide a new configuration 
> file and management library to capture the properties of data-links, 
> when SMF already provides similar capabilities through libscf(3LIB). 
> Other tools such as ksslcfg(1M) are already using SMF for this purpose. 
> But the value that this can bring to the rest of Solaris architecture in 
> the longer term is appealing as well.
> 
I am fine to make SMF a repository of the *private* data-link configuration. 
But at this time, I don't expect to make each link is exposed as a service, 
and change the current dladm model to SMF administrative model to administer 
link configuration.

> Clearview is clearly focusing on the usability aspects of network 
> interface management, and SMF is a big part of the management story of 
> Solaris, so I was hoping to see the view of the Clearview team on how 
> they see this evolving in the long term.
> 
Clearview makes the network administrative model to be more uniform, and 
this clearly benefit any potential effort once it is clear what future 
management model would be.

Thanks
- Cathy

Reply via email to