All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: "backports@vger.kernel.org" <backports@vger.kernel.org>
Subject: taking backports out of compat-*.h (was: [PATCH 02/18] compat: backport dev_level_ratelimited())
Date: Thu, 11 Apr 2013 16:44:17 +0200	[thread overview]
Message-ID: <1365691457.8272.64.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <1365614155.4235.27.camel@jlt4.sipsolutions.net> (sfid-20130410_191605_116427_ECB60701)

On Wed, 2013-04-10 at 19:15 +0200, Johannes Berg wrote:

> > Sure, lets what's the idea or do you want to do that on another thread?

Let me give it a different subject :-)

> 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?

In addition to what I said, I just realized that we should probably do
this, and do it consistently even for old things. That way, we can get
rid of all the pr_fmt patches.

The reason for the pr_fmt patches is that typically, a source file would
have

#define pr_fmt(fmt)           KBUILD_MODNAME ": " fmt
#include <whatever, including somehow getting printk.h>

Now that we force them to include compat-2.6.h at the very beginning of
the file, printk.h already gets included in some way through
compat-2.6.h (there are of course MANY MANY paths to it.)

To avoid redefine warnings, we thus patch everything to be

#undef pr_fmt
#define pr_fmt
...

which of course works, but it's pretty ugly (we have >1000 patchlines
for this!)


If we were able to get rid of compat-2.6.h and put all the backports
into their appropriate headers (linux/foo.h) we could only force an
include of compat_autoconf.h (which doesn't include printk.h of course)
and then we'd be able to get rid of all these patches.

johannes


  reply	other threads:[~2013-04-11 14:44 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10 11:35 [PATCH 00/18] backports: pending patches for Luis Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 01/18] backports: enable DRM_NOUVEAU for 3.2 Luis R. Rodriguez
2013-04-10 13:15   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 02/18] compat: backport dev_level_ratelimited() Luis R. Rodriguez
2013-04-10 13:16   ` Johannes Berg
2013-04-10 17:07     ` Luis R. Rodriguez
2013-04-10 17:15       ` Johannes Berg
2013-04-11 14:44         ` Johannes Berg [this message]
2013-04-11 14:56           ` taking backports out of compat-*.h Hauke Mehrtens
2013-04-10 11:35 ` [PATCH 03/18] compat: backport __i2c_transfer() Luis R. Rodriguez
2013-04-10 13:20   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 04/18] compat: backport devm_regmap_init() Luis R. Rodriguez
2013-04-10 13:19   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 05/18] compat: backport GPIOF_OPEN_DRAIN definition Luis R. Rodriguez
2013-04-10 13:18   ` Johannes Berg
2013-04-10 17:10     ` Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 06/18] compat: backport ASYNC_DOMAIN_EXCLUSIVE() Luis R. Rodriguez
2013-04-10 13:22   ` Johannes Berg
2013-04-10 17:13     ` Luis R. Rodriguez
2013-04-10 17:20       ` Johannes Berg
2013-04-10 17:26         ` Luis R. Rodriguez
2013-04-10 18:20           ` Johannes Berg
2013-04-10 19:19             ` Luis R. Rodriguez
2013-04-10 19:27               ` Johannes Berg
2013-04-10 19:32                 ` Luis R. Rodriguez
2013-04-10 19:39                   ` Johannes Berg
2013-04-10 19:40                     ` Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 07/18] compat: backport devres_release() Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 08/18] compat: backport dev_get_regmap() Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 09/18] compat: backport devm_ioremap_resource() Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 10/18] compat: backport module_platform_driver_probe() Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 11/18] compat: add helpers to aid backport of generic DMA changes for v4l Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 12/18] compat: backport dma_get_sgtable() Luis R. Rodriguez
2013-04-10 13:26   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 13/18] backports: add blacklist module support Luis R. Rodriguez
2013-04-10 13:35   ` Johannes Berg
2013-04-10 19:57     ` Luis R. Rodriguez
2013-04-10 20:00       ` Johannes Berg
2013-04-10 11:35 ` [PATCH 14/18] backports: add support for module compression Luis R. Rodriguez
2013-04-10 13:40   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 15/18] backports: add check_depmod to look for module search path Luis R. Rodriguez
2013-04-10 13:43   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 16/18] backports: add udev rules if required for backported firmware_class Luis R. Rodriguez
2013-04-10 13:45   ` Johannes Berg
2013-04-10 13:47   ` Johannes Berg
2013-04-10 20:12     ` Luis R. Rodriguez
2013-04-10 11:35 ` [PATCH 17/18] backports: use depmod -a Luis R. Rodriguez
2013-04-10 13:46   ` Johannes Berg
2013-04-10 11:35 ` [PATCH 18/18] backports: add update-initramfs support Luis R. Rodriguez
2013-04-10 13:48   ` Johannes Berg
2013-04-10 20:12     ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1365691457.8272.64.camel@jlt4.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=backports@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.