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

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