Sowmini.Varadhan at Sun.COM wrote: > To revive this thread: I summarized all the comments > exchanged in this thread, along with subsequent 1x1 discussions > with a couple of folks at > http://opensolaris.org/os/project/brussels/files/brussels2.pdf > > Some interesting topics for discussion are on how to deal > with current methods for configuring interfaces particularly > using the network/physical:default service, and also how > to organize the current "flags" related info dumped out > by ifconfig in some useful way.. I've put out some thoughts > there- comments/opinions are invited. >
One of your comments in the document is whether or not the link flags should be delegated to dladm - I'd vote yes. It presents both architectural neatness as well as administrative simplicity (you're not looking in IP settings to change link layer stuff.) And similarly, consider that IPMP things should be left to the ipmp tools? With respect to the API, one thing that concerns me is if you wish to map "ipadm foo-bar" to ipadm_foo_bar()", how do you handle options that are optional, especially if/when new ones are added? What sort of administrative interface is being planned to manage the IPv6 scope? And I'd back Alan Maguire's call for a "-t"... the libipadm needs to support this anyway, in order to properly provide stubs for ifconfig (which does nothing in a persistent fashion.) To be more nitpicky, section 2.6.2 doesn't seem very self consistent... When displaying the properties, I think you've got two different sets of properties to consider. The first is those that have been applied to interfaces that are currently configured. The second is the set of properties that are to be applied to interfaces that are at some point in time configured. I think the first set are your properties and the second set are your plumb time configuration parameters. It may even be appropriate to break up your properties into two groups below that: those that are related to IP intefaces and those that are related to the protocols themselves. For example, what does it mean to use ipadm to set tcp_smallest_anon_port for bge0? Or are there plans to make properties such as these per-IP interface too? I don't think the first paragraph of 5.2 makes a lot of sense. What you're really running into is the confusion between IP interface names and data link names. Having a type for each won't fix the confusion, which is generally a user input error. i.e the user doesn't understand that "hme0:1" isn't what they should be snoop'ing on. Changing the type won't change what the user enters and thus not what the programs uses. A better example would be useful. Darren
