linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Jesper Juhl <juhl-lkml@dif.dk>
Cc: juhl-lkml@dif.dk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][0/4] let's kill verify_area
Date: Thu, 6 Jan 2005 17:56:07 -0800	[thread overview]
Message-ID: <20050106175607.6b15b8e3.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0501070246160.3430@dragon.hygekrogen.localhost>

Jesper Juhl <juhl-lkml@dif.dk> wrote:
>
> On Thu, 6 Jan 2005, Andrew Morton wrote:
> 
> > Jesper Juhl <juhl-lkml@dif.dk> wrote:
> > >
> > > verify_area() if just a wrapper for access_ok() (or similar function or 
> > > dummy function) for all arch's.
> > 
> > This sounds more like "let's kill Andrew".  I count 489 instances in the
> > tree.  Please don't expect this activity to take top priority ;)
> > 
> Heh, right, there's an aspect I hadn't really considered.
> I'm not expecting top priority, not at all. This is nowhere near being 
> anything important, just something that should happen eventually - so I 
> thought, why not just deprecate it now and let it be cleaned up over time 
> (and I'll do my share, don't worry :)
> 
> Accept the patch if you think it makes sense, drop it if you think it does 
> not (or should wait). 

The way to do this is to fix up the callers first, in just ten or so
patches.  Then mark the function deprecated when most of the conversion is
done.

If we deprecate the functions first then 10000 people send small fixes via
various snaky routes and it's really hard to coordinate the overlapping
fixes.  The s/MODULE_PARM/module_param/ stuff did that, because we made it
warn first, then I held the big sweep patch off for 2.6.11.

  reply	other threads:[~2005-01-07  1:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07  1:18 [PATCH][0/4] let's kill verify_area Jesper Juhl
2005-01-07  1:26 ` Andrew Morton
2005-01-07  1:49   ` Jesper Juhl
2005-01-07  1:56     ` Andrew Morton [this message]
2005-01-09  1:20       ` Jesper Juhl

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=20050106175607.6b15b8e3.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=juhl-lkml@dif.dk \
    --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;
as well as URLs for NNTP newsgroup(s).