Re: [PATCH RFC v3 03/13] sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE - Uwe Kleine-König

From: "Uwe Kleine-König" <u.kleine-koenig@baylibre.com>
To: Mauricio Faria de Oliveira <mfo@igalia.com>
Cc: Kees Cook <kees@kernel.org>,
	Joel Granados <joel.granados@kernel.org>,
	 Nathan Chancellor <nathan@kernel.org>,
	Nicolas Schier <nsc@kernel.org>,
	 "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	 Jakub Kicinski <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	 kernel-dev@igalia.com, linux-riscv@lists.infradead.org,
	linux-kernel@vger.kernel.org,  fsverity@lists.linux.dev,
	keyrings@vger.kernel.org, bpf@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org,
	netdev@vger.kernel.org,  linux-wpan@vger.kernel.org,
	lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	 coreteam@netfilter.org, linux-sctp@vger.kernel.org,
	linux-rdma@vger.kernel.org,  linux-s390@vger.kernel.org,
	bridge@lists.linux.dev, mptcp@lists.linux.dev,
	 rds-devel@oss.oracle.com, virtualization@lists.linux.dev
Subject: Re: [PATCH RFC v3 03/13] sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE
Date: Tue, 25 Aug 2026 10:24:12 +0200	[thread overview]
Message-ID: <ao1P_mEJdyRExG3v@monoceros> (raw)
In-Reply-To: <4aa22e41e8ff4bab6638cf0baaa9d07b@igalia.com>

[-- Attachment #1: Type: text/plain, Size: 2301 bytes --]

Hello,

On Mon, Aug 24, 2026 at 06:04:03PM -0300, Mauricio Faria de Oliveira wrote:
> On 2026-08-23 19:12, Uwe Kleine-König wrote:
> > On Sat, Aug 22, 2026 at 01:57:24PM -0300, Mauricio Faria de Oliveira wrote:
> >> On 2026-08-22 10:41, Uwe Kleine-König wrote:
> >> > On Wed, Aug 19, 2026 at 03:16:16PM -0300, Mauricio Faria de Oliveira wrote:
> >> >> The MODULE_SYSCTL_TABLE macro emits a struct module_sysctl_table variable
> >> >> with pointers to a sysctl table's path and entries, and table/entry sizes.
> >> > 
> >> > That new struct doesn't seem to contain any pointer?
> >> 
> >> The struct module_sysctl_table fields .path and .table are pointers,
> >> although with kernel_ulong_t type so that the same 32/64-bit size is
> >> used in file2alias.c based on KERNEL_ELFCLASS (and not on the host,
> >> which might differ with CROSS_COMPILE).
> > 
> > Cross compilation isn't an issue for the already existing device id
> > structures; many of them also contain pointers.
> > (While modpost doesn't use the pointers, the size of the structures must
> > be known to correctly interpret the arrays.)
> 
> Indeed. I missed some device_id structures with pointers, and that
> devicetable-offsets.c is cross-compiled to generate
> devicetable-offsets.h for file2alias.c to use offsets and sizes of the
> target architecture.
> 
> I'll change .path and .table to pointers in the next version.

I *think* the existing device-id structs use char[] for strings that are
relevant for modpost. I look forward to you finding out if there is
still a justification for that :-D

> > I would be great if your series didn't introduce a new obstacle for
> > [CHERI].
> 
> Absolutely. I'll be happy to adjust the series and testing for that.
> 
> Could you please confirm one should just follow [1], which uses [2] to
> build the LLVM toolchain, and use it to build the kernel [3]?
> 
> [1] https://github.com/cheri-linux#building-and-running
> [2] https://github.com/cheri-linux/buildroot
> [3] https://github.com/CHERI-Alliance/linux/tree/codasip-cheri-riscv-7.1

I used
https://github.com/CHERI-Alliance/meta-cheri/tree/codasip-scarthgap and
didn't care about toolchain and rootfs. It also has qemu integrated, so
you can actually test it.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]