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
signature.asc
Description: PGP signature
