Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id struct

Hi,

On Mon, Apr 20, 2026 at 07:39:32PM +0200, Christian A. Ehrhardt wrote:
> 
> Hi,
> 
> On Mon, Apr 20, 2026 at 06:08:16PM +0900, Takashi Sakamoto wrote:
> > Just out of curiosity, what does the CHERI extension adopted to RISC-V
> > architecture require in terms of kernel programming? Is taking extra
> > care when storing pointer values in long-type variables sufficient in
> > driver code?
> 
> That is a significant part but there is more to it (entry code,
> register size changes, the UABI should better be CHERI aware, ...).
> 
> But the issue that a pointer does not fit into an unsigned long
> is an issue that pops up all over the kernel while most other
> changes are more localized.
> 
> There is a working linux kernel in the CHERI alliance github here:
>    https://github.com/CHERI-Alliance/linux/tree/codasip-cheri-riscv-6.18
> That definitely needs more cleanup but it does work.
> Previous work from ARM for the morello project (another CHERI
> enabled platform) is available here:
>    https://git.morello-project.org/morello/kernel/linux
> These should give a rough idea of what is required.
> 
> Fixing unsigned long vs. uintptr_t issues helps a lot with this
> because it reduces the diff. But it is also a general cleanup.

Thsnks for the references. It looks like there is not much to consider
outside of mm subsystem. But I have some concerns if supporting
ARM/RISC-V adoptation of CHERI extension in Linux FireWire subsystem.

Any structures in UAPI header of this subsystem are defined with
an assumption that the size of pointer in the existing System V
architectures is up to 64 bits at most. We can see many usage of
'__u64' type member for pointers (e.g. 'rom' in fw_cdev_get_info
structure). I imagine to need defining specific structures for this kind
of 'fat' pointer. (The same assumption lays on compat ioctl.)

As another concern is that the padding in structure. As long as I know,
any 64 bit architecture for System V ABI has 8 bit alignment rule, and
any structure in UAPI header of this subsystem are carefully defined not
to have different sizes between x86/32bit/64bit architectures, except for
'fw_cdev_event_response' structure (see 'drivers/firewire/uapi-test.c').
As a quick glance, the size of pointer in ARM CHERI extension seems to be
129 bit. In this case, what size of alignment rule is applied? Is there
7 bit padding after pointer member in any aggregates?


Thanks

Takashi Sakamoto