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

On Wed, Apr 22, 2026 at 10:40:09AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> On Wed, Apr 22, 2026 at 10:30:24AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > On Wed, Apr 22, 2026 at 10:19:21AM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 21, 2026 at 04:07:42PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > > > On Tue, Apr 21, 2026 at 09:53:57PM +0900, Takashi Sakamoto wrote:
> > > > > On Mon, Apr 20, 2026 at 07:39:32PM +0200, Christian A. Ehrhardt wrote:
> > > > > > On Mon, Apr 20, 2026 at 06:08:16PM +0900, Takashi Sakamoto wrote:

...

> > > > > Thanks 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.)
> > > > 
> > > > The Standard C answer to that is: The assumption that you can fit a
> > > > pointer in an unsigned long or u64 is not generally justified. This is
> > > > "only" given for all current Linux archtectures. And if you want an
> > > > integer type to store a pointer, use uintptr_t.
> > > 
> > > No, please don't. Linus was clear about this. Use `unsigned long` in that case.
> > 
> > On CHERI we have sizeof(unsigned long) = 4 and sizeof(void *) = 8, so
> > what Linus wants doesn't work.
> 
> Correction, we have sizeof(unsigned long) = 8 and sizeof(void *) = 16 or
> course.

CHERI is not specified for 32-bit platforms?

-- 
With Best Regards,
Andy Shevchenko