>>>> d. dladm_write_conf() >>>> >>>> What exactly do you mean an update collision? Does it strictly check >>>> <linkname, linkid> mapping collision or it checks other attribute as >>>> well? For example, the processing of a modify-aggr subcommand would be: >>>> >>>> dladm_read_conf(linkid, &conf); >>>> dladm_set_conf_field(conf, FPOLICY, &attrp->ld_policy, >>>> DLADM_TYPE_UINT32); >>>> dladm_write_conf(conf); >>>> >>>> Is that enough? Will it cause update collision? (because the link >>>> and specific conf field already exist and this is an update operation.) >>>> >>> >>> The update collision I had in mind was if someone updated the >>> configuration since the last read. Using your example above, if another >>> process updated the persistent storage between the call to >>> dladm_read_conf and the call to dladm_write_conf, dladm_write_conf would >>> return DLADM_STATUS_COLLISION. >>> >> So that you will check the thread the caller belongs to? How? >> > > Here's how I think it would work. We can add an extra door parameter to > the door argument structures. When someone reads a conf (say through > dladm_read_conf or dladm_create_conf) they get a timestamp. When they > try to modify the conf structure, they pass the timestamp via the door > call. linkmgmtd checks the timestamp (which is the time this > configuration data was read) and if the last time the structure was > written was later than this timestamp, the writer gets an update > collision. Otherwise, linkmgmtd updates the last time the configuration > was updated with the current time, and sends a new timestamp back to the > writer. Thoughts? > Sure. It should work. But we don't need to add an extra door parameter as the timestamps should be stored in the dladm_conf_t handle.
Also, a serial number should do the work, we don't need the timestamp. Thanks - Cathy
