> 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(). 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
