> > http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf > Dan,
I had a look of the updated document and I agreed with Meem on most of his comments, plus more comments below: > Thanks for the revised document; here's my next round of feedback on > section 3: > > * The handling of `name' in dladm_create_dlconf() seems imprecise. > For instance, it seems the caller cannot request *just* a > specific instance (e.g., "foo3"). Instead, what if: > > * When `name' ends with a number, it be taken literally, > and the function fails if it's already in-use. > * When `name' does not end in a number, the function > selects the next available instance. > Actually for this API, I don't think there is any case that the caller needs the API to suggest a netN name. The only case that needs this is the kernel (for a physical link), and in that case, if we choose to give the physical link a default name the same as its device instance name, the above approach still does not work. I thin we don't need this API to suggest any name for now, and for the kernel API, we could have an extra argument to explicitly indicate whether the caller like to get a suggestive name or not. > * Having to specify that a configuration be persisted both via > dladm_create_dlconf() and via dladm_commit_dlconf() seems odd. > Why is this necessary? > Right, and I would think that persistent argument should go to the dladm_commit_dlconf() function. Note that dladm_create_dlconf() must check both the persistent and the active configuration to see whether the specific name is already used. ... and we need a persistent argument for the dladm_walk_link() and dladm_destroy_dlconf() function too. Regarding locking, I know that you are researching on SMF right not. But I would expect the locking can be per-link and per-system, especially for the active configuration. Thanks - Cathy
