From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16F03C433F5 for ; Sun, 6 Mar 2022 18:57:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AD1A6B0071; Sun, 6 Mar 2022 13:57:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0344E6B0072; Sun, 6 Mar 2022 13:57:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3F796B0073; Sun, 6 Mar 2022 13:57:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id CD2F36B0071 for ; Sun, 6 Mar 2022 13:57:37 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7DCDC181DA55E for ; Sun, 6 Mar 2022 18:57:37 +0000 (UTC) X-FDA: 79214870154.25.B077449 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 0F0D0A0002 for ; Sun, 6 Mar 2022 18:57:36 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id e8so17596743ljj.2 for ; Sun, 06 Mar 2022 10:57:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qj6QUg+mPOSXqYLVwnSwOPcd0+aQB4PrpOLySbesqDI=; b=NMdTtTNbaeoZJonHKJ7sJZqrEn56YUSwRiX+/WQ0gNQDpclgZ5aR/0+mk6g/KddsP0 2DuCPmlqJF+5nGNp29W3gYMO6pJnxRA25xUksW95XPX/Sa5KYs1R/5iJHFFju6S8BJGd O+hpanaAaaNd2mWW4m2T892GFgKi9WPRzhkKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qj6QUg+mPOSXqYLVwnSwOPcd0+aQB4PrpOLySbesqDI=; b=yJ67sQPB864Wjpv5QAaYxVUXt3tHL+H0fkQ724vaEnbRvBvRjf8t0LAbAqGYAYmcTj 7/URkViA78OPXvTLr7Os9n268zzxfBVe9nhkw3WYmWY8vX8NcE00gwva7b5qGIq/2Thb khVSyNWroaMxfCh5WXxN3A/AVMPixJwKRFQRB5dy/5NGqd6G9Ir/PjrdkHfD9MBHNejr tikui3CYR88SwBqaFyPumpwd3SCDPeB9MviMyLOK7cxrawQrvogdbUTFNa1+eOl0p8PL KJj88N/KK4CJuhjtT5LefeW7bdJ6yGl+NZlBZTA2MW5Pydj8AXxuDvi9ltXfOyf5w4dE 2IQQ== X-Gm-Message-State: AOAM531KS5kk5iHqI4ZBLA8hH6svIlplgqQ3gIH4prKZRgsDlWtVOp4V F596DxwnSGdm6S+oH8fVKRrIlpaugJArDV4vqmo= X-Google-Smtp-Source: ABdhPJxBs1yY0OSw/lQKyFsOqAdoifFn7G61bCyK2wKYrfq3Og9WMW1iwMPoH9dfS86kV4qdiBaGAw== X-Received: by 2002:a2e:b8c5:0:b0:247:e1ba:1f7 with SMTP id s5-20020a2eb8c5000000b00247e1ba01f7mr2445815ljp.349.1646593055062; Sun, 06 Mar 2022 10:57:35 -0800 (PST) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com. [209.85.167.48]) by smtp.gmail.com with ESMTPSA id u14-20020ac258ce000000b004481d5c1b0bsm1523257lfo.38.2022.03.06.10.57.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Mar 2022 10:57:32 -0800 (PST) Received: by mail-lf1-f48.google.com with SMTP id g39so22755633lfv.10 for ; Sun, 06 Mar 2022 10:57:31 -0800 (PST) X-Received: by 2002:ac2:41cf:0:b0:448:1eaa:296c with SMTP id d15-20020ac241cf000000b004481eaa296cmr5694758lfi.52.1646593051338; Sun, 06 Mar 2022 10:57:31 -0800 (PST) MIME-Version: 1.0 References: <20220304025109.15501-1-xiam0nd.tong@gmail.com> <634CBC77-281E-421C-9ED9-DB9E7224E7EA@gmail.com> In-Reply-To: <634CBC77-281E-421C-9ED9-DB9E7224E7EA@gmail.com> From: Linus Torvalds Date: Sun, 6 Mar 2022 10:57:15 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/6] list: add new MACROs to make iterator invisiable outside the loop To: Jakob Koschel Cc: Xiaomeng Tong , Arnd Bergmann , Greg Kroah-Hartman , Jann Horn , Kees Cook , Linux Kbuild mailing list , Linux Kernel Mailing List , Linux-MM , Netdev Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0F0D0A0002 X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NMdTtTNb; dmarc=none; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.173 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Stat-Signature: ym6d5ibyg3kedknz7amabyboy174b7sz X-HE-Tag: 1646593056-749848 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Mar 6, 2022 at 4:19 AM Jakob Koschel wrote: > > I guess we could apply this to list_for_each_entry() as well > once all the uses after the loop are fixed? I think that would be a good longer-term plan. "list_traverse()" ends up being simpler syntactically, and has a certain level of inherent type safety (not just the "don't expose the mis-typed head pointer after the loop"). > I feel like this simply introduces a new set of macros > (we would also need list_traverse_reverse(), list_traverse_continue_reverse() > etc) and end up with a second set of macros that do pretty much > the same as the first one. I think that if we're happy with this, we can probably do a scripted conversion. But I do like how it's incremental, in that we wouldn't necessarily have to do it all in one go. Because it's always really painful with flag-day interface changes, which it would be to actually change the semantics of "list_for_each_entry()" without a name change. It just makes for a lot of pain for things that aren't in-tree yet (not just drivers that are out-of-tree in general, but drivers in development etc). And I really disliked the "pass the type to the list_for_each()" macro, because of how it made the end result look more complex. But list_traverse() looks like it would make the end result better both from a user perspective (ie the code just looks simpler) but also from the type safety point. > Personally I guess I also prefer the name list_for_each_entry() over list_traverse() > and not having two types of iterators for the same thing at the same time. I absolutely agree with you in theory, and in many ways I like list_for_each_entry() better as a name too (probably just because I'm used to it). But keeping the same name and changing how it works ends up being such a "everything at once" thing that I don't think it's realistic. Linus