Re: [RFC PATCH] i2c: Support Smbus 3.0 block sizes up to 255 bytes.

[Wolfram Sang <wsa@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]


> > 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! :)


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]