Hello Olof, On 11/19/2014 09:45 PM, Olof Johansson wrote: >> Is true that this is a new API for mainline but there is a lot of ChromeOS >> installations that depends on this API which means that just replacing the >> kernel with a mainline one there, will break existing user-space programs. > > I think we can deal with that, at least if we pick new ioctl numbers > so we can tell from the userspace tool which interface is in use > during transition. > >> But I understand that since those binaries were using a non-ustream kernel >> it is expected that the kernel API could be changed. >> >> I think it would be great to keep existing binaries working but if changing >> the API is required, then I can certainly do that when doing a re-spin. > > I think there's some value in that, but i'm also somewhat embarrassed > to have missed this aspect when doing internal review, and do agree > with Alan. :) And we have only a few tools that use this interface so > we should be able to cope with it. > >
Thanks a lot for your feedback. I'll follow Alan suggestion then and make the structs to be 64-bit safe and properly padded. Also, I'll follow your suggestion and use a different magic number for the IOCTLs so user-space programs can be backward compatible if needed. > -Olof > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
