Dan Groves wrote: > Cathy Zhou wrote: >>> I don't understand why dladm would need to call delete_linkid if you're >>> temporarily deleting a link. I think if you're temporarily deleting a >>> link, you'd want to keep the link ID to name mapping around so that the >>> link ID is not reused. Even if that wasn't a concern (say if guaranteed >>> that we would never reuse link IDs even after the mapping was >>> deleted), I still don't see why we couldn't bring the link down without >>> deleting the mapping. >>> >> Well. If this linkid was created for a temporary link only, it should >> be deleted when that link is destroyed. >> > > Ahh, because if we didn't, we could potentially run out of link IDs. > > I see. > >>> If knowing the state of the link was important, I would say we should >>> track that using the configuration structures. We could have a field >>> indicating if a link is active. When the system reboots, the link >>> becomes active and the field would be changed to true. >>> >> But this configuration structure is only used for persist data, right? >> and if the link is purely temporary, the configuration structure is >> not involved at all. >> > > You're right, I'm going down the wrong path here. > > Let me think about the affects of the flag you suggested. >
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. 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
