On Thu, Dec 26, 2019 at 08:35:16AM -0800, Ben Greear wrote: > On 12/26/2019 02:05 AM, Jouni Malinen wrote: > > On Mon, Mar 18, 2019 at 01:46:34PM -0700, greearb@xxxxxxxxxxxxxxx wrote: > > > And, if user tries to delete a neigh entry that is already deleted, > > > return OK instead of failure. > > > > But I dropped this part since it seems to be completely separate item > > from the main change and would change the existing interface in a manner > > that does not seem to be necessary and may be unexpected and > > furthermore, it breaks the rrm_neighbor_db test case. > > Would you consider a version of this patch that took an extra 'force' > or similar argument? While automating this, we would rather the > delete not fail if the target is already gone: The system is already in > the desired state, so automation should not need to deal with any > extra fault recovery in this state. Why would this extra complexity be needed in hostapd instead of the tool that issues these remove operations for not existing entries simply ignore the result code? The "target is already gone" is not really accurate, i.e., the target might never have been in the first place.. This sounds like a pretty special case and I'd have the caller ignore the result for such a special case; adding " force" or something similar to the command just to hardcode the result value to be "OK" seems excessive. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
