Re: [PATCH 02/18] compat: backport dev_level_ratelimited()

[Johannes Berg <johannes@sipsolutions.net>]

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