From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailtransmit04.runbox.com (mailtransmit04.runbox.com [185.226.149.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C553C27FD5B for ; Thu, 27 Nov 2025 09:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.226.149.37 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764236262; cv=none; b=UcFniunovKnhw63o2bLVaXUHwPMuSL0bU+7RdWmKjQlF1KHV0VSWgiT0uCrIb27Q8HpcjZDFE6J2p25SmBxX6uctwbTFsZkV7BfSxiE/6ZSpkbAQQUw8h1vY/Rs9xzdz9bir5q0n+WjopKw2v/y3xgeRMuLkstrKRfRqF4TIvvc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764236262; c=relaxed/simple; bh=qRKILHjPf+eicQ27ZGLZIujkwrxJl1WXrtSNAFvimBw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ibCWY8sL5gHp+d0sX/xPKt4XWWvIrg9Ne1CQ7Hu5178ufYq162TF5AeXGBnJ4Q/o2ecIqOFnNVuMC5CWGC4jUd9f8HriWajjYMqhw51RlUwIotjFHUxkjcr+YvsUeIFp93s3gmHBBuveBXtpfagWOiMobb01v68JYvFwcBOGGT4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=runbox.com; spf=pass smtp.mailfrom=runbox.com; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b=QKbjCI7i; arc=none smtp.client-ip=185.226.149.37 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=runbox.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=runbox.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=runbox.com header.i=@runbox.com header.b="QKbjCI7i" Received: from mailtransmit02.runbox ([10.9.9.162] helo=aibo.runbox.com) by mailtransmit04.runbox.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1vOYRP-00CGc0-L1; Thu, 27 Nov 2025 10:37:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=selector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version: References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=fz3wpVmmQEdjalAqxPw3lra+PxXa1nD1aBm6fZYjy5c=; b=QKbjCI7iiV0K2x4VuGzOwmzMdj MMQGY63TkuzNgzzheb0K2B7q81LrLZ+sb4S/hV8GFu+cAKhbQXV7kRoEiTvhDzdJvTrtj2PjgK03q /Ub8BZk0rggEg2CHJ9bgLqqOUN2ZH0Yzvhfu0u9IBFkWZU1v02Ji0z6AVIQi+TkL4r2YKvMn4L4Bc qDHR6LDrbzYNFl6PD0nNWtC9abOV80uqHs+zJRWMiPSBEGLTcioFXWeRtOTCs/Z5kU038TELlAmkZ t4LQmSVhQdd0YxWrfP5ie4ZqqVau3t0Aire+C9Dx9yDfiS3EXTortFNaLb80L1g7esmPC9FFOVwhz eM2jZmpQ==; Received: from [10.9.9.73] (helo=submission02.runbox) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1vOYRP-0002Z1-34; Thu, 27 Nov 2025 10:37:31 +0100 Received: by submission02.runbox with esmtpsa [Authenticated ID (1493616)] (TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256) (Exim 4.93) id 1vOYRB-00GxvM-B7; Thu, 27 Nov 2025 10:37:17 +0100 Date: Thu, 27 Nov 2025 09:37:13 +0000 From: david laight To: Linus Torvalds Cc: Rasmus Villemoes , "Yury Norov (NVIDIA)" , Linus Walleij , Nicolas Frattaroli , linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/21] lib: add alternatives for GENMASK() Message-ID: <20251127093713.5a0f9d95@pumpkin> In-Reply-To: References: <20251025164023.308884-1-yury.norov@gmail.com> <87ldjtuppl.fsf@prevas.dk> <20251126221718.6c595c57@pumpkin> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 26 Nov 2025 15:47:28 -0800 Linus Torvalds wrote: > On Wed, 26 Nov 2025 at 14:17, david laight wrote: > > > > Mark B. will accuse you of abusing ?: :-) > > Compared to '__is_constexpr()', this is child's play. Not *that* is > abusing the ternary op. > > > I've just looked at a .i file. > > GENMASK() currently expands to 855 chars plus four copies of each argument. > > Yeah, I don't love it. It's a horrid macro. But because of the odd > order of arguments, it needs all that crazy checking. > > That said, I do think it could be simplified. Particularly if we just > make the rule be that GENMASK _has_ to take just constant values. > > Right now, I think 99.9% of all users are constants, and we spend a > lot of effort on the 0.1% that isn't. There is the other 0.1% that actually need an 'integer constant expression'. They stop you using ({ ...}). I doubt there are many (if any) for FIELD_PREP() and FIELD_GET() and using auto _mask = mask; would shrink those massively. (If there are any I suspect you are the only person who can fix them in one release cycle.) I've not looked closely at the expansions, but as well as some is_constexpr() (that could probably be 'statically_true()') there is the _Generic() that generates u8/u16/u32/u64 based on 'something'. That is mostly entirely pointless, you just need to pick u32 or u64, the u8/u16 get promoted to 'int' as soon as they are used - so it only makes a difference to code that looks at the type of the variable/result. In spite of the faffing, the type of FIELD_GET() is u64. David > > Linus >