Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp376582imm; Tue, 5 Jun 2018 22:08:47 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIDrQzE5q+itsqgU7UQSxhLfPXJJG8ZwXWvdX9OuA5Mz8X6M4zNvaF5z8k1AMH2bmO56NXJ X-Received: by 2002:a63:bf0b:: with SMTP id v11-v6mr1337747pgf.29.1528261726939; Tue, 05 Jun 2018 22:08:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528261726; cv=none; d=google.com; s=arc-20160816; b=iME2vIJfhRK8Ei4d5dRbjQ9axAechPk9npY9xTQUAxim2dbXlPVaj0nYlDselqOcg2 6DNFPbLDPF9LwWpcjlr5W1vZY/Sahueo9xxYWY573IIz981TgEcNoFdslHQLmF01MlXC EMynTxu8bPGyb96RxYhnebtQUKOL53eR74UM8REjL20uTJpDle4DA80G5NkuVMpzLNv3 Hj4DvpkxMvOSoBeJBsOac72hpmGIjZKrsaHhYx4XyaZw/yLkKLG8X6ceNCJb+4DyC8Rq qo8/OHZIN0JKGwKE+R4vxWvLh6nAISc1wfHHcmtmh7/Ue0VjEvxP4wULC4L5VEKCtK5V TBYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:references :in-reply-to:subject:cc:date:to:from:arc-authentication-results; bh=9jqVvIuafDLznp9J4c3oiyDT1rx8x3uKhk241eoQlHE=; b=rwDUvCsT7OERe6UIz431+LtlBhtwbITIf/W2egigJm2Qj1XcliT9wHDvoyq2z1HraG AlcrF23TxLyGTvw0dxgXXdOpGQQ4ULDUSLbm3VnNu6UgVtgTCiAxrmbLUXgedaka0kvT lWEpqrD+9ZY3UpsfmuikXe+e67o1zasyiAGuMetVrhowd7eWfc/MSByJ+ZOSVd0B39yv GUnZM11Y5XYPLsHST/OwBijLVeRjgtR6IeUdx7k/+TbpvlaJzIgv+7anndsY/PADAYTT yv6nmggJQXFKTT0J/MyqKdqa2rQ5/X46oZtcq+cUPqxFQ47j2aySpa/JynnSgAiVYTQS tRcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s9-v6si4211511pfm.257.2018.06.05.22.08.32; Tue, 05 Jun 2018 22:08:46 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751971AbeFFFII (ORCPT + 99 others); Wed, 6 Jun 2018 01:08:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:48304 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750785AbeFFFIH (ORCPT ); Wed, 6 Jun 2018 01:08:07 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 9754CACBB; Wed, 6 Jun 2018 05:08:05 +0000 (UTC) From: NeilBrown To: Tom Herbert Date: Wed, 06 Jun 2018 15:07:57 +1000 Cc: Herbert Xu , Thomas Graf , Linux Kernel Network Developers , LKML , Tom Herbert Subject: Re: [PATCH 10/18] rhashtable: remove rhashtable_walk_peek() In-Reply-To: References: <152782754287.30340.4395718227884933670.stgit@noble> <152782824964.30340.6329146982899668633.stgit@noble> <20180602154851.pfy4wryezuhxp76v@gondor.apana.org.au> <87y3fvpf40.fsf@notabene.neil.brown.name> <87sh63pakb.fsf@notabene.neil.brown.name> <87r2lmnj2c.fsf@notabene.neil.brown.name> Message-ID: <87in6wo636.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain On Tue, Jun 05 2018, Tom Herbert wrote: > On Mon, Jun 4, 2018 at 6:00 PM, NeilBrown wrote: > >> On Mon, Jun 04 2018, Tom Herbert wrote: >> >> >> >> >> Maybe a useful way forward would be for you to write documentation for >> >> the rhashtable_walk_peek() interface which correctly describes what it >> >> does and how it is used. Given that, I can implement that interface >> >> with the stability improvements that I'm working on. >> >> >> > >> > Here's how it's documented currently: >> > >> > "rhashtable_walk_peek - Return the next object but don't advance the >> iterator" >> > >> > I don't see what is incorrect about that. >> >> rhashtable_walk_next is documented: >> >> * rhashtable_walk_next - Return the next object and advance the iterator >> >> So it seems reasonable to assume that you get the same object, no matter >> which one you call. Yet this is not (necessarily) the case. >> >> >> > Peek returns the next object >> > in the walk, however does not move the iterator past that object, so >> > sucessive calls to peek return the same object. In other words it's a >> > way to inspect the next object but not "consume" it. This is what is >> > needed when netlink returns in the middle of a walk. The last object >> > retrieved from the table may not have been processed completely, so it >> > needs to be the first one processed on the next invocation to netlink. >> >> I completely agree with this last sentence. >> We typically need to process the last object retrieved. This could also >> be described as the previously retrieved object. >> So rhashtable_walk_last() and rhashtable_walk_prev() might both be >> suitable names, though each is open to misinterpretation. >> > > rhashtable_walk_last is better, but still could have the connotation that > it returns the last element in the list or table. How about > rhashtable_walk_last_seen or rhashtable_walk_last_iter? I'd be quite happy with rhashtable_walk_last_seen(). I also be happy to keep rhasthable_walk_peek() but to implement it as rhashtable_walk_last_seen() ?: rhashtable_walk_next() I'll send patches to that effect some time this week. Thanks, NeilBrown --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG8Yp69OQ2HB7X0l6Oeye3VZigbkFAlsXbC0ACgkQOeye3VZi gbkZuhAAsgPnKaVXRaxpSuQjpP/5Uv26QazeZGXEGuqEaywafv5HVuH+ASeh8WUm cY6uTseJ8QGiL3t7wi0lEtC/Iy2bpUj6etS8ScdRnaiv/Ye2Zgi+tL3G1AjOujKf 0mqW+NREBlqRvdJ2fVTdjg3obatwfhhKFObmZk2GCzAMEZ30+K42fkKUVKWk6+vb ARKqycsZ8IvoNRYq4v81Sf4g25LdylotHtdkEN+jfKVn67WoUNAsK3YqtHPHpQGc iA0fFxTdBQPG91zJdgt/IyquVoI+7vfqxgKxFgYGCHg12jK5DHhMKQGBHq4ObShA mJI4YyfOPDnz692oQYztt9+4zmOia+M0j/Yvq8+uXJ9NrA5KmeZ2YvUi542gPS4C JS6uPG0mUEgw6JQOkeqJ6QbnBihQggrfRnurJ22133rnvQEW0hjaYrP6p9W2LIv1 tbPGKqN1q3KaYQr5ix1WqT6k7qkv3Ffd5yaWCbcZPMoYWEMyN1VZWI8KKMpGEvlT stK5ywQl4+VeURG/sAWrYaIWO7/3f+mbJEtYANoM4qwLmC1mC+sJOwKazftmOkxS 9w2nE4XCul7dF/UO/kulcwbblyUuaBL97FEHMCV7TXnbCOJAy/mAK7G+JwXq91SE jhkVWp8yWsFcwPoDtwSXz79o8OgC2qu3N72QsK+N9Kmepekec1E= =A1Fg -----END PGP SIGNATURE----- --=-=-=--