Cathy Zhou wrote: > >> I spent some time today with pen and paper working out different >> scenarios. I see the problem that you brought up. Here's my first >> attempt at adding the flag that you suggest. Note that since there's >> still some discussion about the final names of the functions, I'm >> going to use the names names from the original proposal. >> >> get_new_linkid(name, class, flag) >> >> flag is a field that can be set to PERSIST or TEMP (but not both). >> The flag indicates if the API caller intends to persist the link ID to >> name mapping. The API doesn't do anything with the flag, except make >> a note of it. No matter what flag is, all link ID to name mappings >> generated by this API are temporary unless persisted. >> >> delete_linkid(/* either id or name */, flag) >> >> flag is a field that can be set to either PERSIST or TEMP. > > I suggest that we allow both flags to be set at the same time, that is: > > get_new_linkid(name, class, LINKMGMT_ACTIVE | LINKMGMT_PERSIST) means > that a new link which is both persistent and "active" is created. > > the same applies to delete_linkid(). >
OK, I added it. I'll release the new document soon. thanks, Dan > Thanks > - Cathy > >> If it is set to PERSIST, then the API assumes the caller wants to >> delete the link ID to name mapping and remove it from the persistent >> configuration. The API will delete the link ID to name mapping >> regardless of how the mapping was created. If flag is TEMP, then the >> API will assume that if the mapping was created with the PERSIST flag, >> then the caller wants the mapping restored on the next reboot. In >> this case, the mapping is not deleted, it will remain in whatever data >> structures are used to hold the mapping to prevent a later collision. >> If the flag is TEMP and the mapping was created with the TEMP flag, >> then the mapping is deleted. >> >> The API user can still get into a bad situation. If they call >> delete_linkid using a PERSIST flag on a link created with a PERSIST >> flag, and the API user does not remove the persistent configuration, >> then we could have a collision on reboot. If we introduced a rename >> operation, then we could prevent this. >> >> How does this proposal sound? >> >> thanks, >> Dan > > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org
