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:

quoted

At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:

quoted

On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:

quoted

At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:

quoted

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