Hello Andy,

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.

But let me note that we don't have to resolve that question for this
patch set. We're still far away from working on mainlining the core
changes for CHERI that most probaly will require some casting between
pointers and integer types. My plan for now is to work on changes (like
the one here) where we have both, a benefit for mainline and as a side
effect a simplification for CHERI enablement. So I wouldn't mind to
delay the discussion.

Best regards
Uwe