From: Tilman Schmidt <tilman@imap.cc>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
"Robert P. J. Day" <rpjday@mindspring.com>,
i4ldeveloper@listserv.isdn4linux.de, Karsten Keil <kkeil@suse.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: so what *is* obsolete and removable?
Date: Tue, 17 Apr 2007 19:55:33 +0200 [thread overview]
Message-ID: <46250A15.2010705@imap.cc> (raw)
In-Reply-To: <20070417163337.3b62b8f5@the-village.bc.nu>
[-- Attachment #1: Type: text/plain, Size: 3386 bytes --]
Am 17.04.2007 17:33 schrieb Alan Cox:
> On Tue, 17 Apr 2007 17:03:58 +0200
> Tilman Schmidt <tilman@imap.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@imap.cc
Wehrhausweg 66 Fax: +49 228 4299019
53227 Bonn
Germany
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
prev parent reply other threads:[~2007-04-17 17:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-15 20:55 so what *is* obsolete and removable? Robert P. J. Day
2007-04-15 21:45 ` Jiri Slaby
2007-04-15 21:50 ` Jesper Juhl
2007-04-16 14:44 ` Robert P. J. Day
2007-04-16 14:58 ` Adrian Bunk
2007-04-16 22:39 ` Tilman Schmidt
2007-04-16 23:13 ` Randy Dunlap
2007-04-17 12:52 ` Tilman Schmidt
2007-04-17 13:40 ` Alan Cox
2007-04-17 15:03 ` Tilman Schmidt
2007-04-17 15:33 ` Alan Cox
2007-04-17 17:55 ` Tilman Schmidt [this message]
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=46250A15.2010705@imap.cc \
--to=tilman@imap.cc \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=i4ldeveloper@listserv.isdn4linux.de \
--cc=kkeil@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=rpjday@mindspring.com \
/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