On Sat, May 5, 2018 at 2:43 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Fri, May 04, 2018 at 01:54:14PM +1000, NeilBrown wrote: >> rhashtable_walk_prev() returns the object returned by >> the previous rhashtable_walk_next(), providing it is still in the >> table (or was during this grace period). >> This works even if rhashtable_walk_stop() and rhashtable_talk_start() >> have been called since the last rhashtable_walk_next(). >> >> If there have been no calls to rhashtable_walk_next(), or if the >> object is gone from the table, then NULL is returned. >> >> This can usefully be used in a seq_file ->start() function. >> If the pos is the same as was returned by the last ->next() call, >> then rhashtable_walk_prev() can be used to re-establish the >> current location in the table. If it returns NULL, then >> rhashtable_walk_next() should be used. >> >> Signed-off-by: NeilBrown <ne...@suse.com> > > I will ack this if Tom is OK with replacing peek with it. > I'm not following why this is any better than peek. The point of having rhashtable_walk_peek is to to allow the caller to get then current element not the next one. This is needed when table is read in multiple parts and we need to pick up with what was returned from the last call to rhashtable_walk_next (which apparently is what this patch is also trying to do).
There is one significant difference in that peek will return the element in the table regardless of where the iterator is at (this is why peek can move the iterator) and only returns NULL at end of table. As mentioned above rhashtable_walk_prev can return NULL so then caller needs and so rhashtable_walk_next "should be used" to get the previous element. Doing a peek is a lot cleaner and more straightforward API in this regard. Tom > Cheers, > -- > 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