Hi Jan, Michal, I am not sure who maintains genksyms officially, so I am sending this question to the two of you as folks who seemed to have contributed to the tool. :-)
I noticed with genksyms that a symbol is opaquely defined in a public header file (on purpose) and then fully defined in a private header. This is normal practice. Further, symbol checksumming is done on EXPORT_SYMBOLs in a private c file that includes the private header files. As a result, even though a struct symbol is intentionally opaquely defined in a public header file consumed by a third party module, the symbol checksumming still includes the full definition (because the private c file with the actual export symbol has the full definition). This has made it difficult to modify the private header file struct because it breaks the symbol checksumming. For example, let's consider block/blk-core.c:EXPORT_SYMBOL(blk_put_queue); blk_put_queue will eventually depend on struct blkcq_gq. Now publicly blkcg_gq is defined opaquely in include/linux/blkdev.h and privately in block/block-cgroup.h Now when we checksum blk_put_queue both include/linux/blkdev.h and block/block-cgroup.h are included in block/blk-core.c, so blkcg_gq is fully defined for checksumming. Later if we modify blkcq_gq in block/block-cgroup.h the checksum changes, even though it can debated that block-cgroup.h is a private header file and it should not impact kabi for third party modules. Have either of you run into this? Or is the argument that private files should not impact the checksum not as strong as I might think? Or is it a technical problem of how to separate the public includes from the private includes in the preprocessed file? Thanks! Cheers, Don -- 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/
