public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Adrian Bunk <bunk@stusta.de>, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] unexport insert_resource
Date: Sun, 24 Apr 2005 10:52:23 +0100	[thread overview]
Message-ID: <20050424095223.GA22146@infradead.org> (raw)
In-Reply-To: <20050423164411.51d77bf1.akpm@osdl.org>

On Sat, Apr 23, 2005 at 04:44:11PM -0700, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > I didn't find any possible modular usage in the kernel.
> > 
> 
> True, but this looks like something which out-of-tree code could possibly
> be using.  I'd prefer to see this one get the deprecated_for_modules
> twelve-month treatment.

Don't you think twelve month is damn long?  Two kernel releases seem
like a better policy - extremly long deprecation periods only encourage
people to never look at mainline kernels but just ad vendor trees.

> Or we just leave it as-is.  It depends whether insert_resource is a
> sensible part of the resource management API (I think it is).  If so,
> then we should just leave it exported, whether or not any in-kernel moduels
> happen to be using it at this point in time.

It makes sense for plattforms or bus implementations.  So for typical drivers
it doesn't make sense at all.  It might make sense for bus providers, and in
case a modular one that wants this symbol appears we could re-export it
as _GPL, clearly marking it internal.

Note that you're not really helping driver authors by exporting random
kernel symbols - that way we can never guarantee a semi-stable API as
random internals are exported.  Compare that with e.g. the scsi subsystem
where we're trying to make sure to only export sensible primitives that
operate on higher-level object to the driver and make sure they're moving
off old and ill-specified APIs.


  parent reply	other threads:[~2005-04-24  9:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15 15:10 [2.6 patch] unexport insert_resource Adrian Bunk
2005-04-23 23:44 ` Andrew Morton
2005-04-24  8:58   ` Arjan van de Ven
2005-04-24  9:52   ` Christoph Hellwig [this message]
2005-04-24 10:14     ` Andrew Morton
2005-05-02  1:45   ` [2.6 patch] __deprecated_for_modules insert_resource Adrian Bunk
2005-05-02 10:54     ` Arjan van de Ven
  -- strict thread matches above, loose matches on Subject: below --
2005-03-04  0:48 [2.6 patch] unexport insert_resource Adrian Bunk

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=20050424095223.GA22146@infradead.org \
    --to=hch@infradead.org \
    --cc=akpm@osdl.org \
    --cc=bunk@stusta.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox