On Wed, 2013-04-10 at 10:07 -0700, Luis R. Rodriguez wrote: > > I think, however, that it would be easier to understand if we started > > putting less stuff into compat-xyz.h and more into linux/feature.h? > > Needs more discussion though I guess. > > Sure, lets what's the idea or do you want to do that on another thread? It's kinda half-baked and I'm not completely sure it's a good idea (because we may have to follow header file renames, though they happen rarely), but I was basically thinking this: Say there's void my_foo_function(struct foo *f); that we want to backport. Let's also say it's defined in <linux/foo.h>, and that it was usually present starting from kernel 3.0, but for now let's assume the "foo" subsystem always existed (i.e. <linux/foo.h>) Typically, we'd therefore add it to <linux/compat-3.0.h> and declare it there, maybe with the LINUX_BACKPORT() wrapper, and then define it in compat/compat-3.0.c. What I'm thinking is that we should maybe declare it in compat in include/linux/foo.h instead, maybe like this: #ifndef __BACKPORT_FOO #define __BACKPORT_FOO #include_next <linux/foo.h> #if LINUX_VERSION < 3.0 #define my_foo_function LINUX_BACKPORT(my_foo_function) void my_foo_function(struct foo *f); #endif #endif /* __BACKPORT_FOO */ I'm a bit undecided. On the one hand I think it's nice that we can spot in one place what's backported where in all the include/linux/compat-xyz.h files, but on the other hand it's kinda becoming a messy jumble of features across different subsystems, and hard to determine what you have already and might need for a given header file? Anyway it's probably not even half-baked yet :) johannes -- 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
