[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hod1lorpm.wl%tiwai@suse.de>
Date: Thu, 16 Oct 2008 10:43:33 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Adrian Bunk <bunk@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>,
linux-ext4@...r.kernel.org, netdev@...r.kernel.org,
linux-ide@...r.kernel.org,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
marek.vasut@...il.com, David Woodhouse <dwmw2@...radead.org>,
Mark Fasheh <mark.fasheh@...cle.com>,
Ralf Baechle <ralf@...ux-mips.org>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...abs.org
Subject: Re: powerpc allmodconfig
At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
>
> On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
> > At Thu, 16 Oct 2008 10:38:36 +0300,
> > Adrian Bunk wrote:
> > >
> > > On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
> > > > At Wed, 15 Oct 2008 21:33:37 -0700,
> > > > Andrew Morton wrote:
> > > > >
> > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > > > sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is deprecated (declared at sound/soc/soc-dapm.c:1026)
> > > >
> > > > These are definitions of deprecated interfaces.
> > > > We can remove it in 2.6.29. If we don't want to be conservative, it
> > > > can be removed in 2.6.28, too.
> > > >...
> > >
> > > Since it's an in-kernel API there's no reason to keep it once there are
> > > no users left.
> >
> > Right. But, IMO, now is no suitable time.
> > A thing like API removal should have been tested in linux-next, and we
> > had plenty of time indeed for 2.6.28.
> >...
>
> A grep through the tree and one test compile that covers
> sound/soc/soc-dapm.c should be enough testing.
>
> And having it then in -next once should be enough to discover if someone
> wrongly added a new user.
My point is the time for removal. The API changes should have been
done in the merge window, and it should have been tested *before* the
merge window.
> I have removed many functions in the kernel, and there isn't much that
> can go wrong - even adding a PCI ID to a driver has a bigger risk of
> introducing a regression.
Yeah, IMHO, adding PCI IDs blindly at the late stage should be
avoided, too, although many people love that.
thanks,
Takashi
--
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