> > 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:
signature.asc
Description: PGP signature
