On 2026-08-23 19:12, Uwe Kleine-König wrote: > Hello Mauricio, > > 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. > Also sizeof(long) differs between architectures and I can compile for > arm(32) just fine on amd64. > > Additionally there is hardware out there that has sizeof(void *) = 16 > but sizeof(long) = 8. Up until recently I worked on mainlining that (and > it has business reasons only I stopped, so I guess and hope I will > continue at some point in the future). See > https://lwn.net/Articles/1037974/ for some details if you're interested. Cool. > > I would be great if your series didn't introduce a new obstacle for > that. 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 >> >> That symbol will be handled by file2alias.c (modpost) with the changes in >> >> mod_devicetable.h and devicetable-offsets.c. >> >> >> >> The option macros MODULE_SYSCTL_TABLE_{DISABLE,UNIQUE_ID} can be used on >> >> a per-file basis to disable the macro and change the symbol name pattern. >> >> >> >> Signed-off-by: Mauricio Faria de Oliveira <[email protected]> >> >> --- >> >> include/linux/mod_devicetable.h | 7 +++++++ >> >> include/linux/sysctl.h | 42 >> >> +++++++++++++++++++++++++++++++++++++++ >> >> scripts/mod/devicetable-offsets.c | 6 ++++++ >> >> 3 files changed, 55 insertions(+) >> > >> > Please put the new struct in a separate header. Apart from not being >> > about a device table, I'm currently work on removing >> > <linux/mod_devicetable.h>. See commit >> > ad428f5811bd7fb3d91fa002174de533f9da94d7 for more details. >> >> Sure; I looked at that earlier (thanks for the instructive commit >> message, by the way) and found the new struct to be similar to "struct >> cpu_feature isn't really a device_id struct" (not moved), but apparently >> missed the trailing "fow now", which is clearer now. Fixed for v4. > > Yeah, I didn't move that because it was an outlier in the header as it's > not a device id. IMHO it should go to something like > include/linux/cpu_feature.h. Ack. cheers, > > Best regards > Uwe -- Mauricio
