<!DOCTYPE html>
<!-- BaNnErBlUrFlE-BoDy-start -->
<!-- Preheader Text : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">
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</div>
<!-- Preheader Text : END -->
<!-- Email Banner : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;"></div>
<!-- Email Banner : END -->
<!-- BaNnErBlUrFlE-BoDy-end -->
<html>
<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
#pfptBannerfnkl274 { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #c2d4d4 !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtonfnkl274:hover, .pfptPrimaryButtonfnkl274:focus {
background-color: #a2b1b1 !important; }
.pfptPrimaryButtonfnkl274:active {
background-color: #828e8e !important; }
html:root, html:root>body { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important; }
</style>
<!-- BaNnErBlUrFlE-HeAdEr-end -->
</head><body><pre style="font-family: sans-serif; font-size: 100%; white-space: pre-wrap; word-wrap: break-word">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 <mfo@igalia.com>
>> >> ---
>> >> 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
</pre></body></html>