Message-ID: <46250A15.2010705@imap.cc>
Date:	Tue, 17 Apr 2007 19:55:33 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Randy Dunlap <randy.dunlap@...cle.com>,
	"Robert P. J. Day" <rpjday@...dspring.com>,
	i4ldeveloper@...tserv.isdn4linux.de, Karsten Keil <kkeil@...e.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: so what *is* obsolete and removable?

Am 17.04.2007 17:33 schrieb Alan Cox:
> On Tue, 17 Apr 2007 17:03:58 +0200
> Tilman Schmidt <tilman@...p.cc> wrote:
> 
>> On Tue, 17 Apr 2007 14:40:54 +0100, Alan Cox wrote:
>>> If the obsolete tag is to be removed then it needs a formal maintainer,
>>> all the obsolete interface usage cleaning up and the like otherwise at
>>> some point in a clean up it is going to end up breaking and migrating to
>>> && BROKEN as well.
>> I'm not sure I understand. What do you mean by "obsolete interface
>> usage"? What sort of cleaning up needs to be done? What sort of
>> breakage do you anticipate in the event of a clean up?
> 
> Things like:
> 
> 	pci_find_device
> 	pci_find_bus
> 
> 	interruptible_sleep_on
> 	sleep_on
> 
> 	lock_kernel
> 	unlock_kernel
> 
> and the drivers that i4l uses (eg hisax) need switching to the proper
> pci_module interfaces to handle hot plug.

I was afraid you meant that. You are confirming my worst fears.
So it's already too late, and that incorrect obsolete tag is on its
way to becoming a self-fulfilling prophecy. Whatever happened to the
promise in Documentation/stable_api_nonsense.txt:

| <insert link to leech comment from Andrew and Linus here>.)  If your
| driver is in the tree, and a kernel interface changes, it will be fixed
| up by the person who did the kernel change in the first place.  This
| ensures that your driver is always buildable, and works over time, with
| very little effort on your part.

?

Let me guess: the person who did the kernel change in the first place
saw that I4L was marked as obsolete anyway, and therefore didn't bother
fixing it up. And now that very fact constitutes a reason to keep that
label, ensuring that future people doing kernel changes will do
likewise. So the cat is biting its own tail, as we say in German.

Well, end of rant. So the situation now is:
- A discussion on LKML concluded that the isdn4linux subsystem is not
  obsolete today, given that a complete replacement does not yet exist.
- The "obsolete" tag on the ISDN_I4L Kconfig entry is therefore
  incorrect.
- In order to remove it, you ask that the code of the isdn4linux
  subsystem be modified to conform to certain changes that have been
  made to the kernel API but not extended to isdn4linux.
- The people best qualified to make these modifications are
  (a) those who introduced the kernel API changes in the first place or
  (b) the isdn4linux maintainers.
- The isdn4linux maintainers are busy working on the new CAPI subsystem
  and mISDN driver which should replace isdn4linux eventually but are
  not quite there yet. (mISDN not even being in the kernel so far.)
- That leaves those who introduced the kernel API changes in question
  to finish what is, according to stable_api_nonsense.txt, their job.
- In the meantime, we'll have to live with the recurring question
  whether the isdn4linux subsystem can finally be scheduled for removal.
- At least we are safe against an actual removal, because that would
  constitute a regression (break existing functionality that is in
  actual use), and Linus says we don't do regressions.

Did I sum that up correctly?

Thanks
Tilman

-- 
Tilman Schmidt                                  E-Mail: tilman@...p.cc
Wehrhausweg 66                                  Fax: +49 228 4299019
53227 Bonn
Germany


Download attachment "signature.asc" of type "application/pgp-signature" (254 bytes)

Powered by blists - more mailing lists