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

--lpqo3i3mqf5ctrqo
Content-Type: text/plain; protected-headers=v1; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH v1 0/2] firewire: Simplify storing pointers in device id
 struct
MIME-Version: 1.0

On Wed, Apr 22, 2026 at 12:40:43PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 22, 2026 at 10:40:09AM +0200, Uwe Kleine-K=F6nig (The Capable=
 Hub) wrote:
> > On Wed, Apr 22, 2026 at 10:30:24AM +0200, Uwe Kleine-K=F6nig (The Capab=
le 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=F6nig (The C=
apable 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 wr=
ote:
>=20
> ...
>=20
> > > > > > Thanks for the references. It looks like there is not much to c=
onsider
> > > > > > outside of mm subsystem. But I have some concerns if supporting
> > > > > > ARM/RISC-V adoptation of CHERI extension in Linux FireWire subs=
ystem.
> > > > > >=20
> > > > > > 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.)
> > > > >=20
> > > > > 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. Th=
is is
> > > > > "only" given for all current Linux archtectures. And if you want =
an
> > > > > integer type to store a pointer, use uintptr_t.
> > > >=20
> > > > No, please don't. Linus was clear about this. Use `unsigned long` i=
n that case.
> > >=20
> > > On CHERI we have sizeof(unsigned long) =3D 4 and sizeof(void *) =3D 8=
, so
> > > what Linus wants doesn't work.
> >=20
> > Correction, we have sizeof(unsigned long) =3D 8 and sizeof(void *) =3D =
16 or
> > course.
>=20
> CHERI is not specified for 32-bit platforms?

(Attention, half-knowledge alert; take the stuff I'm saying with a grain
of salt.)

There are 32bit riscv CHERI machines (even real hardware[1], while for
64 bit riscv there is currently only qemu and an expensive FPGA by
Codasip), but a difficulty there is that there is >1 incompatible
variant about the semantics of the additional pointer bits which makes
working on that a bit more difficult and ugly. And I'm not aware of an
effort to make Linux work on those. Also I believe that all users who
want CHERI and Linux will stick to 64bit.

Best regards
Uwe

[1] https://lowrisc.org/news/unveiling-sonata-affordable-cheri-hardware-for=
-embedded-systems/

--lpqo3i3mqf5ctrqo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmnono4ACgkQj4D7WH0S
/k6YZQf9FUngrLtMCr92GyMX0DLthDD65eSi2ROyDx6P7CzGggQZgP1/WBa7dwgg
80pyPUF7K7juQkdYWLZq12SpRYGRraItX7p21mP0Ubv5VFxGZMTCbwUi5mSKOd0/
+Gabdj844qXtseKTPl8RiM7/n+7IbauFp44rr7l05FAUW9GVk6VSFvQhAXwVwIfI
TJWshiTH9VQoi4ylpqneEksXynnUCcUc4kJwQN9P+wNVI4bTbb7lAY4JIQsrpATm
U4HW/znVhyslzkRRz3yLDiOPPxPGsBE2+lVlJEWlR9QF/RFlnmy7Hl/dmGE/oJMA
YZpeLnclkayY5MgunizbAjYaz07VMg==
=s4rN
-----END PGP SIGNATURE-----

--lpqo3i3mqf5ctrqo--