On Thu, Apr 19, 2018 at 09:08:07AM +1000, NeilBrown wrote: > > The need is essentially the same as the need for > rhashtable_walk_peek(). The difference is that the actual behaviour can > be documented briefly (and so understood easily) without enumerating > multiple special cases. > rhashtable_walk_peek() is much the same as > rhashtable_walk_prev() ?: rhashtable_walk_next() > > The need arises when you need to "stop" a walk and then restart at the > same object, not the next one. i.e. the last object returned before the > "stop" wasn't acted on. > This happens with seq_file if the buffer space for ->show() is not > sufficient to format an object. In the case, seq_file will stop() the > iteration, make more space available (either by flushing or by > reallocing) and will start again at the same location. > If the seq_file client stored the rhashtable_iter in the seq_file > private data, it can use rhasthable_walk_prev() to recover its position > if that object is still in the hash table. If it isn't still present, > rhashtable_walk_next() can be used to get the next one. In some cases > it can be useful for the client to know whether it got the previous one > or not.
I see. I'm OK with this provided that you will also remove/convert users of rhashtable_walk_peek. I don't think we need two functions that do almost the same thing. Thanks, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
