Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1727429pxv; Sat, 10 Jul 2021 13:11:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxuPFuW24h0Lj58AqusR4xJlVnheg3PMp1LKzdQUKj+5nT06ayF+VtCv0VVbwFLMmLb+dK2 X-Received: by 2002:a17:906:71b:: with SMTP id y27mr9470212ejb.80.1625947882716; Sat, 10 Jul 2021 13:11:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625947882; cv=none; d=google.com; s=arc-20160816; b=qEfDU08J12cf/BykMdGTq0bP9KXsF+GovHfE963eWvCnzc7+MyP1N+Ngo7F0aKBqc5 alpEMUSlPGHoUL6Q3U9j8cV7W8P+uravR52pIH1RfVrM80KVzJXAb5l0OeiO2VtKY6js cuopdfpIbxRGU2jd6uQ6JXWonh6XdDZoWvPiAvfK+4BZ1qyQQAljAA4yIieU2tkbzxVo O0TO7Oc5tzkuz4c+NFKWVie8fFTlXCvAV4VTW6ElZgPf2ih/QH9ZB61nxxxN+rV9c0n7 ZFNepSTrtmriMWtnQdw/2+TAmunm9pJVGdYB9OO9bGxnIkAbg1f5/uVCNlRDneGlS0js RbKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:ironport-hdrordr; bh=KRVt9ZNYmJmTiYRts2LubnnHv/9NnDm/VWXjB+eOZzc=; b=ZybVUnmfamcjjWqTDoWMy3VazHlY0nezNEP41ke5AMZ+4sdaGc0sEzoSX3HzWOW+bu Bh25JrAfD1cqyGF0APE3TMHvt19IYn279qEEv9UGwsNqEbcCZwLG4uiXQxN4naQMbdDx /j0ydgZG3rB4Y9Om6AqCoO2THrCNhdfEiWGH1c7sUSYBKMK8Epd6/gPFqchJ+GIkSlE3 PuuvHwrFJpuoK1fFeXp5JAE+chrnNQLEwZZZOqO52t/Z0HoV8w8/uI/tA+/kjnkZevd1 pj+b8aw2StedaefNEYXWq2lJiIIUDpRFbkKFqiI5IqR2jV3tbSdDRTsRheH4bpI552L+ dqTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c10si12846028edm.514.2021.07.10.13.11.00; Sat, 10 Jul 2021 13:11:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231131AbhGJUME (ORCPT + 99 others); Sat, 10 Jul 2021 16:12:04 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:44487 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229515AbhGJUMC (ORCPT ); Sat, 10 Jul 2021 16:12:02 -0400 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ay1++66M4chlPfMBcTsajsMiBIKoaSvp037BL?= =?us-ascii?q?7TEUdfU7SKelfqyV9sjzkCWUtN9zYgBEpTnjAsm9qBrnnPZICMsqTNSftWLd1l?= =?us-ascii?q?dAQrsP0WKv+UyDJwTOst8Y76tmfqRkYeecMXFxh6/BjzWFLw=3D=3D?= X-IronPort-AV: E=Sophos;i="5.84,229,1620684000"; d="scan'208";a="387686079" Received: from 173.121.68.85.rev.sfr.net (HELO hadrien) ([85.68.121.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2021 22:09:15 +0200 Date: Sat, 10 Jul 2021 22:09:15 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Joe Perches cc: cocci , LKML , kernel-janitors@vger.kernel.org Subject: Re: cocci script to convert linux-kernel allocs with BITS_TO_LONGS to bitmap_alloc In-Reply-To: Message-ID: References: <08b89608cfb1280624d1a89ead6547069f9a4c31.camel@perches.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 10 Jul 2021, Joe Perches wrote: > On Sat, 2021-07-10 at 21:50 +0200, Julia Lawall wrote: > > On Fri, 9 Jul 2021, Joe Perches wrote: > > > > > Here is a cocci script to convert various types of bitmap allocations > > > that use BITS_TO_LONGS to the more typical bitmap_alloc functions. > > > > > > Perhaps something like it could be added to scripts/coccinelle. > > > The diff produced by the script is also below. > > > > > > $ cat bitmap_allocs.cocci > > > // typical uses of bitmap allocations > [] > > > @@ > > > expression val; > > > expression e1; > > > expression e2; > > > @@ > > > > > > - val = kcalloc(BITS_TO_LONGS(e1), sizeof(*val), e2) > > > + val = bitmap_zalloc(e1, e2) > > > > Is there something that guarantees that val has a type that has a size that > > is the same as a long? > > no, but afaict, all do. It might be nicer for the val metavariable to be declared as {long,unsigned long} val;, although that might lose some results if the type is something else that has the same size. I can check what is the impact of adding that constraint. julia