> > I thought about this, too, and wondered if this isn't a size regression
> > in userspace with every i2c_smbus_data getting 8 times the size? But
> > maybe it is worth if backwards compatibility is maintained in an
> > otherwise not so intrusive manner? Jean, what do you think?
> 
> Yep, exactly. It just made for a nice drop-in replacement for me to
> focus on i2c-dev.c first.
> 
> A lot of clients will stack-allocate these. I suppose i2-tools doesn’t
> load more than one at a time, but haven’t looked.

I just checked all in-kernel users and i2c-tools. Never more than one.
Which is kind of expected because you usually re-use i2c_smbus_data and
move the buffer contents somewhere else.

> Retrospectively
> - i2c_smbus_ioctl_data.data shouldn’t have been a pointer type, but is.
> - i2c_smbus_data.block should have been pointer, but isn’t
> 
> And then the kernel would pass around an 32-bit-only i2c_smbus_data union -- by value.
> Which would have been much leaner, and leave the right buffer choice
> entirely to the client.
> 
> One could explore this in kernel space. Let me know how you’d like to experiment.

? I'd like to keep kernel space and user space in sync. Why should we
have a different i2c_smbus_data-variant in the kernel space? Or did I
get you wrong.

> But in userspace that means we’re looking at a new call number. >:)

No way! :)