Re: [PATCH RFC v3 03/13] sysctl, mod_devicetable: add macro MODULE_SYSCTL_TABLE

[Mauricio Faria de Oliveira <mfo@igalia.com>]

On 2026-08-25 05:24, Uwe Kleine-König wrote:
> 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

AFAICT, an array is simpler to read in file2alias as it is stored
directly in the symbol:

For example:

@ include/linux/device-id/of.h 

	struct of_device_id {
	...
		char compatible[128];
	...

@ drivers/net/ethernet/korina.c

	static const struct of_device_id korina_match[] = {
		{
		        .compatible = "idt,3243x-emac",
	...
	MODULE_DEVICE_TABLE(of, korina_match);

which builds

	$ objdump -t drivers/net/ethernet/korina.o | grep __mod_device_table
	0000000000001020 l     O .rodata	0000000000000190
__mod_device_table__kmod_korina__of__korina_match

	$ objdump -s -j .rodata --start-address=0x1020
--stop-address=$((0x1020+0x190)) drivers/net/ethernet/korina.o
	...
	 1020 00000000 00000000 00000000 00000000  ................
	 1030 00000000 00000000 00000000 00000000  ................
	 1040 00000000 00000000 00000000 00000000  ................
	 1050 00000000 00000000 00000000 00000000  ................
	 1060 6964742c 33323433 782d656d 61630000  idt,3243x-emac..
	 1070 00000000 00000000 00000000 00000000  ................
	...

@ scripts/mod/file2lias.c

	#define DEF_FIELD_ADDR(m, devid, f) \
		typeof(((struct devid *)0)->f) *f = ((m) + OFF_##devid##_##f)

	static void do_of_entry(struct module *mod, void *symval)
	{
	...
		DEF_FIELD_ADDR(symval, of_device_id, compatible);
	...
	
void handle_moddevtable(struct module *mod, struct elf_info *info,
                        Elf_Sym *sym, const char *symname)
{
        void *symval;
...
                symval = sym_get_data(info, sym);

On the other hand, a pointer is stored indirectly through a relocation
in the symbol, which is not as simple to read (i.e., 1. find the
relocation section for the symbol's section; 2. find the relocation in
that section by matching relocation offsets with an offset in the symbol
+ symbol address; 3. finally read the relocation's target).

>> > 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.

I'll take a look; thanks!

cheers,

> 
> Best regards
> Uwe

-- 
Mauricio