On Thu, Apr 4, 2013 at 7:12 PM, Andy Gospodarek <andy@xxxxxxxxxxxxx> wrote: > On Tue, Apr 02, 2013 at 02:42:56PM -0700, Luis R. Rodriguez wrote: >> I should note that RHEL / SUSE / Debian all had the same issues -- >> running into symbols we are exporting with the same upstream name. The >> move to use LINUX_BACKPORT() should help cure these issues in general >> moving forward. Additionally if you really want to help in this area >> please review commit 8ae96730 on compat.git specifically Andi Kleen's >> work on module namespace. If we can figure out to support module >> namespace *ourselves*, ie, without Linus having to carry this crap >> around, then we'd solve all these issues easily, I believe we wouldn't >> have to rely on LINUX_BACKPORT() and in fact that would also mean >> renaming our *driver* symbols. This means for instance you can run one >> drivers with your stock mac80211, another with the backported version, >> should you ever have to support such crazy environement. >> > > As I was watching the patches for LINUX_BACKPORT fly past over the last > few weeks and making changes to allow RHEL to work with compat, I > wondered, "Why not add the LINUX_BACKPORT macro to each one of the > symbols backported?" Its sort of already done and committed! > Of course that seems extremely tedious, but is there a compelling reason > why something like this should not be done -- other than possibly doing > as Luis suggests and finding a way to resurrect Andi Kleen's proposal > for module symbol namespaces -- then I think the option to begin a more > liberal use of the LINUX_BACKPORT macro is worth considering. Johannes some idea to help with the tedious work of doing this moving forward for new code. I'll let him dive in when he awakens. Luis -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
