public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>, torvalds@linux-foundation.org
Subject: Re: [PATCH] Permit silencing of __deprecated warnings.
Date: Thu, 25 Oct 2007 04:20:56 -0400	[thread overview]
Message-ID: <472051E8.2070005@garzik.org> (raw)
In-Reply-To: <20071025011516.aea17222.akpm@linux-foundation.org>

Andrew Morton wrote:
> On Thu, 25 Oct 2007 04:06:13 -0400 (EDT) Jeff Garzik <jeff@garzik.org> wrote:
> 
>> The __deprecated marker is quite useful in highlighting the remnants of
>> old APIs that want removing.
>>
>> However, it is quite normal for one or more years to pass, before the
>> (usually ancient, bitrotten) code in question is either updated or
>> deleted.
>>
>> Thus, like __must_check, add a Kconfig option that permits the silencing
>> of this compiler warning.
>>
>> This change mimics the ifdef-ery and Kconfig defaults of MUST_CHECK as
>> closely as possible.
> 
> Sigh.  Can't we just fix the dud code?  Or mark it BROKEN and see what
> happens?

__deprecated has spread to just about every API that people don't 
consider fresh and up-to-date.

Like I noted in the patch description, rewriting grotty ISA/MCA/etc. 
probe code is a thankless, boring task that few are crazy enough to 
attempt :)

As you can see from the patch flood recently I /have/ been working 
through the dud code, but it will still take years.  The changes 
required for each are on average ~200 LOC changed, if not more.

But regardless...  I don't see any reason to force every kernel build to 
remind us of grotty drivers.  Where's the benefit?  Everybody knows they 
are grotty.

Like __must_check this option defaults to the current state of things -- 
warnings -- so you have to take an extra step to turn them off.

	Jeff




  reply	other threads:[~2007-10-25  8:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-25  8:06 [PATCH] sound/oss/sb_common.c: fix casting warning Jeff Garzik
2007-10-25  8:06 ` [PATCH] Permit silencing of __deprecated warnings Jeff Garzik
2007-10-25  8:15   ` Andrew Morton
2007-10-25  8:20     ` Jeff Garzik [this message]
2007-10-25 15:34     ` Linus Torvalds
2007-10-25 11:02   ` Sam Ravnborg
2007-10-26  3:07   ` Arjan van de Ven
2007-10-25  8:06 ` [PATCH] Remove #warnings for longstanding conditions Jeff Garzik
2007-10-25  9:52   ` Karsten Keil
2007-10-25 11:22   ` Matthew Wilcox
2007-10-26  2:07     ` Jeff Garzik
2007-10-26  2:14       ` Matthew Wilcox
2007-10-26  2:19         ` Jeff Garzik
2007-10-25  8:06 ` [PATCH] ISDN/capidrv: fix casting warning Jeff Garzik
2007-10-25  9:51   ` Karsten Keil
2007-10-26  0:53     ` Jeff Garzik

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=472051E8.2070005@garzik.org \
    --to=jeff@garzik.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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