On Thu, 24 Nov 2016 08:36:39 +0100 Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote: > > But still, modversions is pretty complicated for what it gives us. It sends > > preprocessed C into a C parser that makes CRCs using type definitions of > > exported symbols, then turns those CRCs into a linker script which which is > > used to link the .o file with. What we get in return is a quite limited and > > symbol "versioning" system. > > > > What if we ripped all that out and just attached an explicit version to > > each export, and incompatible changes require an increment? > > How would that work for structures? Would that be required for every > EXPORT_SYMBOL* somehow? Yeah just have EXPORT_SYMBOL take another parameter which attaches a version number and use that as the value for the __crc_ symbol versions rather than a calculated CRC. Yes it would require some level of care from developers and may be a small annoyance when changing exports. But making people think a tiny bit more before chnaging exported ABI shouldn't be the end of the world. > > > Google tells me > > Linus is not a neutral bystander on the topic of symbol versioning, so I'm > > bracing for a robust response :) (actually I don't much care either way, I'm > > happy to put a couple of bandaids on it and keep it going) > > There are tools that people are working on to make it more obvious where > API breaks happen by looking at the .o debug data instead of our crazy > current system (which is really better than nothing), perhaps we should > start using them instead? > > See here for more details about this: > https://kernel-recipes.org/en/2016/talks/would-an-abi-changes-visualization-tool-be-useful-to-linux-kernel-maintenance/ Hmm. I guess it's basically similar to modversions, so has downsides of not detecting a semantic change unless it changes the type. But still, if we could replace our custom code with a tool like this for modversions functionality, that alone would be a massive improvement. But requiring debug info might be a bit of a show stopper. I also don't know if that would handle asm functions. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
