[<prev] [next>] [day] [month] [year] [list]
Message-ID: <47506A4F.6010109@keyaccess.nl>
Date: Fri, 30 Nov 2007 20:53:51 +0100
From: Rene Herman <rene.herman@...access.nl>
To: trenn@...e.de
CC: Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
"yakui.zhao" <yakui.zhao@...el.com>,
"Li, Shaohua" <shaohua.li@...el.com>,
Bjorn Helgaas <bjorn.helgaas@...com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Andrew Morton <akpm@...l.org>,
ALSA devel <alsa-devel@...a-project.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sound/isa: kill pnp_resource_change.
On 30-11-07 18:39, Thomas Renninger wrote:
> On Fri, 2007-11-30 at 18:19 +0100, Rene Herman wrote:
>> Thomas Renninger is making some haste with the deprecation of the removed
>> functions by the way -- I just saw a patch of his entering my mailbox where
>> he says he'd in fact like them deprecated in 2.6.24 already. The ALSA
>> removal would not seem likely to be scheduled to go to 2.6.24 yet, so I
>> guess that won't do?
>>
>> I have no opinion on the schedule -- but Thomas, if you do, I guess you'd
>> need to convince Jaroslav to withstand The Wrath Of Linus and ask him to
>> push it. We can't have it deprecated (on the "spew warnings" level) with
>> ALSA still using them in 2.6.24.
>
> Why not?
> The intend of __deprecated is to throw some compile warnings?
> In this case it would warn on the official 2.6.24 on functions which are
> known to be reverted already for the next cycle (this should not hurt?),
It does. A clean build is not about esthetics but about quality. Warnings
that are to be ignored hide warnings that are not to be, not just in the
sense of the output but due to humans actively tuning out the noise after
just a few. I'd hate for sound/isa to add to the noise.
> it's more for drivers building against kernel headers getting noticed as
> soon as possible...
>
> If this is not added to 2.6.24, the funcs should live there for another
> kernel cycle just to not print some irrelevant warnings at compile time
> things are slowed down...
This makes sense if someone told you that the deprecation period for
exported symbols is one kernel cycle but who did?
Anyways, two things:
The number of out of tree users of these symbols is very close to zero and
quite possibly if not likely _at_ zero after I've cleaned up the couple of
half-hearted ALSA ISAPnP drivers that I keep in a few local branches here.
As such, and given that removing them apparently clears the path for a long
overdue and welcome PnP cleanup, simply yanking them soon would get my ack.
Second, as said, speak to Jaroslav as well I guess.
> This is also in vanilla and lives there for some time?:
> kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64)
> kernel/power/pm.c:205: warning: ‘pm_register’ is deprecated (declared at kernel/power/pm.c:64)
> kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180)
> kernel/power/pm.c:206: warning: ‘pm_send_all’ is deprecated (declared at kernel/power/pm.c:180)
Exactly, and serves as a perfect reminder of why noone should ever be
allowed to deprecate anything until after removing all in tree users.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists