Re: [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Thu, Oct 25, 2012 at 03:56:33PM +0200, Jean Delvare wrote:
> On Thu, 25 Oct 2012 14:46:09 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 25, 2012 at 03:42:02PM +0200, Jean Delvare wrote:
> > > On Thu, 25 Oct 2012 14:14:59 +0100, Russell King - ARM Linux wrote:
> > > > You also miss one very very very big point.  This will break every I2C
> > > > using userspace program out there unless it is rebuilt - this change will
> > > > require the exact right version of those userspace programs for the
> > > > kernel that they're being used on.
> > > 
> > > How that? The extra field is added in a hole, so we don't change the
> > > struct size nor the relative positions of existing fields. Why would
> > > user-space care?
> > 
> > You know the layout of that struct for certain across all Linux supported
> > architectures, including some of the more obscure ones which may not
> > require pointers to be aligned?
> 
> No I don't, I naively supposed it would be fine. I would expect gcc to
> always align pointers even when the architecture doesn't need them to
> be, for performance reasons, even when it doesn't have to, as long as
> attribute packed isn't used. After all, integers don't _have_ to be
> aligned on x86, but gcc aligns them.
> 
> The original idea of using the hole in the i2c_msg structure is from
> David Brownell, who was apparently familiar with such practice, so I
> assumed it was OK. Actually I still assume it is, until someone comes
> with an supported architecture where it is not.

According to Al Viro, that would be m68k.