hi folks we've talked a bit about the SMF representation of datalinks and interfaces, and how these representations will be present whether NWAM is enabled or not. previously, our API design assumed that manipulation of these entities was an NWAM-specific activity, and as such the API for handling such manipulations was part of libnwam. what i'd like to propose is a library API that is not tied to any network policy engine, provisionally called libnetadm. the aim is to have an API that any policy engine can use to manipulate the link/interface representations. these manipulations include creating/destroying instances, setting/retrieving properties/dependencies, renaming instances etc.
any comments, particularly from the Clearview folks about the adequacy of the API would be appreciated. thanks! http://www.opensolaris.org/os/project/nwam/p1spec/link_interface_API/ alan Max Zhen wrote: > > > Peter Memishian wrote: >> > > Hmm...maybe we can change the name like: >> > > network/datalink:default --> network/datalink-management >> > > network/ip:default --> network/ip-management >> > > >> > > So, we split the management services from individual datalink/ip >> instances. >> > > And we use the same name that Clearview is using now for >> datalink > > management service. >> > > >> > > > that separation would definitely help from an implementation >> > perspective - the management services and datalink/interface >> instances >> > will have different dependencies and exec methods - it would >> certainly >> > make life easier if they could inherit these from the service level. >> >> Our foremost concern should be the resulting administrative model, >> rather >> than the internal complexity of the implementation. Is there an >> administrative justification for having foo and foo-management services? >> > My understanding is that each foo is representing a network interface > in this system (for layer 2 or 3). > While foo-management (or foo:default) is representing a daemon that > can generate/destroy foo. > Logically, they're of different things and there is not much to share > in service level. So, maybe it is good, > if we split them, for: > a) from a administrative view, the name of the instance better shows > that foo is not foo-management. Do > not try to manage foo-management the same way as foo. > b) as pointed out by Alan, it helps from an implementation perspective. > > Max
