Re: [PATCH v2 00/19] `zerocopy` support

On Tue Jun 9, 2026 at 1:21 PM BST, Alice Ryhl wrote:
> On Mon, Jun 08, 2026 at 04:14:19PM +0200, Miguel Ojeda wrote:
>> This patch series introduces support for `zerocopy`:
>>
>>     Fast, safe, compile error. Pick two.
>>
>>     Zerocopy makes zero-cost memory manipulation effortless. We write
>>     `unsafe` so you don't have to.
>
> I tried applying this and using it with Binder. I ran into one
> challenge, which is this uapi struct:
>
> struct binder_transaction_data {
> 	/* The first two are only used for bcTRANSACTION and brTRANSACTION,
> 	 * identifying the target and contents of the transaction.
> 	 */
> 	union {
> 		/* target descriptor of command transaction */
> 		__u32	handle;
> 		/* target descriptor of return transaction */
> 		binder_uintptr_t ptr;
> 	} target;
> 	binder_uintptr_t	cookie;	/* target object cookie */
> 	...
> }
>
> The problem is that when the union contains a handle, there are 4 bytes
> of padding in the union. Currently Rust Binder handles this by wrapping
> the uapi struct in MaybeUninit and using MaybeUninit::zeroed() to
> construct it, ensuring that even if padding is present, it is zeroed.
>
> However, this trick relies on unsafely implementing AsBytes for
> BinderTransactionData with the safety comment being that the MaybeUninit
> actually always contains initialized data.
>
> To translate this to zerocopy, I'd have to do this:
>
> unsafe impl zerocopy::IntoBytes for $newname {
>     fn only_derive_is_allowed_to_implement_this_trait() {}
> }
>
> One fix could be to update the uapi header by explicitly adding the
> padding, but that's kind of awkward for a union like this, since I'd
> have to do it like this with an extra struct:
>
> 	union {
> 		/* target descriptor of command transaction */
> 		struct {
> 			__u32	handle;
> 			__u32	_pad;
> 		};
> 		/* target descriptor of return transaction */
> 		binder_uintptr_t ptr;
> 	} target;
>
> It's not clear to me if changing the uapi headers like this is even
> allowed to begin with. It's a somewhat non-trivial change.
>
> Any better ideas?
>
> Alice

We can patch out `only_derive_is_allowed_to_implement_this_trait`? I don't like
this "extra safeguarding" in the first place. I think the "unsafe" there is
sufficient.

Best,
Gary