<!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-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</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>
#pfptBannerx65vq8b { all: revert !important; display: block !important;
visibility: visible !important; opacity: 1 !important;
background-color: #c2d4d4 !important;
max-width: none !important; max-height: none !important }
.pfptPrimaryButtonx65vq8b:hover, .pfptPrimaryButtonx65vq8b:focus {
background-color: #a2b1b1 !important; }
.pfptPrimaryButtonx65vq8b: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-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
</pre></body></html>