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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
