any value to fixing apparent bugs in old ISDN4Linux?

any value to fixing apparent bugs in old ISDN4Linux?

[Robert P. J. Day]

$ grep -r DE_AOC .
./.config:CONFIG_DE_AOC=y
./drivers/isdn/hisax/l3dss1.c:#ifdef HISAX_DE_AOC
./drivers/isdn/hisax/l3dss1.c:#else  /* not HISAX_DE_AOC */
./drivers/isdn/hisax/l3dss1.c:#endif /* not HISAX_DE_AOC */
./drivers/isdn/hisax/Kconfig:config DE_AOC

  it seems like there's a name mismatch between the config variable
and the one that's being tested, no?

  OTOH, since that code *is* in the allegedly obsolete old ISDN4Linux
code, perhaps that entire part of the tree can just be junked.  but if
it's sticking around, it should probably be fixed.

  unless i'm misreading something up there.

rday

Re: any value to fixing apparent bugs in old ISDN4Linux?

[Karsten Keil]

On Mon, Jan 15, 2007 at 06:43:30AM -0500, Robert P. J. Day wrote:
> 
> $ grep -r DE_AOC .
> ./.config:CONFIG_DE_AOC=y
> ./drivers/isdn/hisax/l3dss1.c:#ifdef HISAX_DE_AOC
> ./drivers/isdn/hisax/l3dss1.c:#else  /* not HISAX_DE_AOC */
> ./drivers/isdn/hisax/l3dss1.c:#endif /* not HISAX_DE_AOC */
> ./drivers/isdn/hisax/Kconfig:config DE_AOC
> 
>   it seems like there's a name mismatch between the config variable
> and the one that's being tested, no?
> 
>   OTOH, since that code *is* in the allegedly obsolete old ISDN4Linux
> code, perhaps that entire part of the tree can just be junked.  but if
> it's sticking around, it should probably be fixed.
> 


Yes thanks for discover this. Since the code only affect the
analyse of the AOC info which is pure information only without real
function it was not detected before.

-- 
Karsten Keil
SuSE Labs
ISDN development

Re: any value to fixing apparent bugs in old ISDN4Linux?

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Robert P. J. Day schrieb:
>   OTOH, since that code *is* in the allegedly obsolete old ISDN4Linux
> code, perhaps that entire part of the tree can just be junked.  but if
> it's sticking around, it should probably be fixed.

Please do not remove isdn4linux just yet. It's true that it has been
marked as obsolete for quite some time, but it's still needed anyway.
Its designated successor, the CAPI subsystem, so far only supports
a very limited range of hardware. Dropping isdn4linux now would leave
the owners of some very popular ISDN cards out in the cold.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: any value to fixing apparent bugs in old ISDN4Linux?

[Robert P. J. Day]

On Mon, 15 Jan 2007, Tilman Schmidt wrote:

> Robert P. J. Day schrieb:
> >   OTOH, since that code *is* in the allegedly obsolete old ISDN4Linux
> > code, perhaps that entire part of the tree can just be junked.  but if
> > it's sticking around, it should probably be fixed.
>
> Please do not remove isdn4linux just yet. It's true that it has been
> marked as obsolete for quite some time, but it's still needed
> anyway. Its designated successor, the CAPI subsystem, so far only
> supports a very limited range of hardware. Dropping isdn4linux now
> would leave the owners of some very popular ISDN cards out in the
> cold.

that wouldn't be my decision, i just made a note of an oddity.  but if
it's still in actual use, then it really should be re-labelled from
"obsolete" to "deprecated," no?

rday

Re: any value to fixing apparent bugs in old ISDN4Linux?

[Karsten Keil]

On Mon, Jan 15, 2007 at 12:17:37PM -0500, Robert P. J. Day wrote:
> On Mon, 15 Jan 2007, Tilman Schmidt wrote:
> 
> > Robert P. J. Day schrieb:
> > >   OTOH, since that code *is* in the allegedly obsolete old ISDN4Linux
> > > code, perhaps that entire part of the tree can just be junked.  but if
> > > it's sticking around, it should probably be fixed.
> >
> > Please do not remove isdn4linux just yet. It's true that it has been
> > marked as obsolete for quite some time, but it's still needed
> > anyway. Its designated successor, the CAPI subsystem, so far only
> > supports a very limited range of hardware. Dropping isdn4linux now
> > would leave the owners of some very popular ISDN cards out in the
> > cold.
> 
> that wouldn't be my decision, i just made a note of an oddity.  but if
> it's still in actual use, then it really should be re-labelled from
> "obsolete" to "deprecated," no?
> 

Good point.

-- 
Karsten Keil
SuSE Labs
ISDN development

[PATCH] Remove "obsolete" label from ISDN4Linux (was: any value to fixing apparent bugs in old ISDN4Linux?)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

Am 15.01.2007 18:29 schrieb Karsten Keil:
> On Mon, Jan 15, 2007 at 12:17:37PM -0500, Robert P. J. Day wrote:
>> [...] but if
>> it's still in actual use, then it really should be re-labelled from
>> "obsolete" to "deprecated," no?
> 
> Good point.

May I?

From: Tilman Schmidt <tilman@imap.cc>

Remove incorrect "obsolete" label from ISDN4Linux

---

--- a/drivers/isdn/Kconfig	2006-11-29 22:57:37.000000000 +0100
+++ b/drivers/isdn/Kconfig	2007-02-21 01:19:19.000000000 +0100
@@ -25,7 +25,7 @@ menu "Old ISDN4Linux"
 	depends on NET && ISDN

 config ISDN_I4L
-	tristate "Old ISDN4Linux (obsolete)"
+	tristate "Old ISDN4Linux subsystem"
 	---help---
 	  This driver allows you to use an ISDN-card for networking
 	  connections and as dialin/out device.  The isdn-tty's have a built
@@ -38,8 +38,8 @@ config ISDN_I4L

 	  ISDN support in the linux kernel is moving towards a new API,
 	  called CAPI (Common ISDN Application Programming Interface).
-	  Therefore the old ISDN4Linux layer is becoming obsolete. It is
-	  still usable, though, if you select this option.
+	  The old ISDN4Linux layer is still available for use with cards
+	  that are not supported by the new CAPI subsystem yet.

 if ISDN_I4L
 source "drivers/isdn/i4l/Kconfig"

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

[Repost][PATCH] Remove "obsolete" label from ISDN4Linux

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

From: Tilman Schmidt <tilman@imap.cc>

Remove incorrect "obsolete" label from ISDN4Linux.

Signed-off-by: Tilman Schmidt <tilman@imap.cc>

---

--- a/drivers/isdn/Kconfig	2006-11-29 22:57:37.000000000 +0100
+++ b/drivers/isdn/Kconfig	2007-02-21 01:19:19.000000000 +0100
@@ -25,7 +25,7 @@ menu "Old ISDN4Linux"
 	depends on NET && ISDN

 config ISDN_I4L
-	tristate "Old ISDN4Linux (obsolete)"
+	tristate "Old ISDN4Linux subsystem"
 	---help---
 	  This driver allows you to use an ISDN-card for networking
 	  connections and as dialin/out device.  The isdn-tty's have a built
@@ -38,8 +38,8 @@ config ISDN_I4L

 	  ISDN support in the linux kernel is moving towards a new API,
 	  called CAPI (Common ISDN Application Programming Interface).
-	  Therefore the old ISDN4Linux layer is becoming obsolete. It is
-	  still usable, though, if you select this option.
+	  The old ISDN4Linux layer is still available for use with cards
+	  that are not supported by the new CAPI subsystem yet.

 if ISDN_I4L
 source "drivers/isdn/i4l/Kconfig"

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

[PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

From: Tilman Schmidt <tilman@imap.cc>

The "obsolete" label on the ISDN_I4L Kconfig option is not, and
has never been, accurate. It has already prompted repeated attempts
to remove actively used functionality from the kernel without a
working replacement. This patch removes the incorrect label and
corrects the accompanying help text.

Signed-off-by: Tilman Schmidt <tilman@imap.cc>

---

--- a/drivers/isdn/Kconfig	2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/isdn/Kconfig	2007-04-21 14:48:54.000000000 +0200
@@ -25,9 +25,9 @@ menu "Old ISDN4Linux"
 	depends on NET && ISDN

 config ISDN_I4L
-	tristate "Old ISDN4Linux (obsolete)"
+	tristate "Old ISDN4Linux subsystem"
 	---help---
-	  This driver allows you to use an ISDN-card for networking
+	  This driver allows you to use an ISDN adapter for networking
 	  connections and as dialin/out device.  The isdn-tty's have a built
 	  in AT-compatible modem emulator.  Network devices support autodial,
 	  channel-bundling, callback and caller-authentication without having
@@ -38,8 +38,9 @@ config ISDN_I4L

 	  ISDN support in the linux kernel is moving towards a new API,
 	  called CAPI (Common ISDN Application Programming Interface).
-	  Therefore the old ISDN4Linux layer is becoming obsolete. It is
-	  still usable, though, if you select this option.
+	  Therefore the old ISDN4Linux layer will eventually become obsolete.
+	  It is still available, though, for use with adapters that are not
+	  supported by the new CAPI subsystem yet.

 if ISDN_I4L
 source "drivers/isdn/i4l/Kconfig"

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Alan Cox]

On Sat, 21 Apr 2007 15:07:51 +0200
Tilman Schmidt <tilman@imap.cc> wrote:

> From: Tilman Schmidt <tilman@imap.cc>
> 
> The "obsolete" label on the ISDN_I4L Kconfig option is not, and
> has never been, accurate. It has already prompted repeated attempts
> to remove actively used functionality from the kernel without a
> working replacement. This patch removes the incorrect label and
> corrects the accompanying help text.
> 
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>

Nak-by: Alan Cox <alan@redhat.com>

If it isn't obsolete then fix the code to use the newer APIs as its about
to end up && BROKEN let alone Obsolete. Make yourself maintainer and go
for it.

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[David Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Sat, 21 Apr 2007 21:58:44 +0100

> On Sat, 21 Apr 2007 15:07:51 +0200
> Tilman Schmidt <tilman@imap.cc> wrote:
> 
> > From: Tilman Schmidt <tilman@imap.cc>
> > 
> > The "obsolete" label on the ISDN_I4L Kconfig option is not, and
> > has never been, accurate. It has already prompted repeated attempts
> > to remove actively used functionality from the kernel without a
> > working replacement. This patch removes the incorrect label and
> > corrects the accompanying help text.
> > 
> > Signed-off-by: Tilman Schmidt <tilman@imap.cc>
> 
> Nak-by: Alan Cox <alan@redhat.com>
> 
> If it isn't obsolete then fix the code to use the newer APIs as its about
> to end up && BROKEN let alone Obsolete. Make yourself maintainer and go
> for it.

This is my opinion too.

There is zero work being done on that subsystem to freshen it up
and make it current in any way.

Lack of a working replacement is not an argument for anything.

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 3089 bytes --]

Am 22.04.2007 00:10 schrieb David Miller:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Sat, 21 Apr 2007 21:58:44 +0100
> 
>> On Sat, 21 Apr 2007 15:07:51 +0200
>> Tilman Schmidt <tilman@imap.cc> wrote:
>>
>>> From: Tilman Schmidt <tilman@imap.cc>
>>>
>>> The "obsolete" label on the ISDN_I4L Kconfig option is not, and
>>> has never been, accurate. It has already prompted repeated attempts
>>> to remove actively used functionality from the kernel without a
>>> working replacement. This patch removes the incorrect label and
>>> corrects the accompanying help text.
>>>
>>> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
>> Nak-by: Alan Cox <alan@redhat.com>
>>
>> If it isn't obsolete then fix the code to use the newer APIs

Why should that be a precondition for removing the incorrect
"obsolete" label?

The code works, and adapting it to newer APIs is the job of those
who introduced those newer APIs in the first place, according to
the oft-touted stable_api_nonsense.txt policy document. In fact I
suspect the incorrect "obsolete" label is a major reason why they
haven't done that job so far.

Anyway, I'm not the right person for that job. I know neither the
code in question nor those newer APIs well enough to do it. I am
just trying to help by correcting an error I found. That doesn't
make me responsible for every other problem that code may have.

>> as its about
>> to end up && BROKEN let alone Obsolete.

That can't happen. Any change that breaks isdn4linux before its
replacement is ready would constitute a regression.
We've been there once, remember?

> There is zero work being done on that subsystem to freshen it up
> and make it current in any way.

Not true. What is true, however, is that the main effort of ISDN
development is currently going into the future replacement for
isdn4linux, the CAPI subsystem. But that's no reason to mark the
current one as obsolete before the time.

> Lack of a working replacement is not an argument for anything.

I beg to differ. Existence of a working replacement is exactly
the criterion we arrived at when discussing the meaning of the
term "obsolete". So lack of a working replacement *is* an
argument for concluding that something is not obsolete.

To sum it up:

- The "obsolete" label on the isdn4linux subsystem is, and has
  always been, incorrect.

- The authors of certain in-kernel API changes seem to have
  neglected the isdn4linux subsystem in their work.

- These are two independent problems. Blocking the correction of
  one of them because the other one still exists doesn't help,
  but only risks deadlock.

I therefore kindly ask you to accept this patch even though I
cannot offer a remedy for the other gripes you have with the
isdn4linux subsystem, and even though you might personally not
have any use for that subsystem.

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Alan Cox]

> >> If it isn't obsolete then fix the code to use the newer APIs
> 
> Why should that be a precondition for removing the incorrect
> "obsolete" label?

Because if we remove the obsolete label the users are going to be
suprised when it goes away entirely with && BROKEN or && !HOTPLUG or
similar.

> >> to end up && BROKEN let alone Obsolete.
> 
> That can't happen. Any change that breaks isdn4linux before its
> replacement is ready would constitute a regression.
> We've been there once, remember?

Want to be on that. There is nobody maintaining it. That isn't a
sustainable situation so it will break.

> I beg to differ. Existence of a working replacement is exactly
> the criterion we arrived at when discussing the meaning of the
> term "obsolete". So lack of a working replacement *is* an
> argument for concluding that something is not obsolete.

Ok then it should be marked "BROKEN" instead.

> - The authors of certain in-kernel API changes seem to have
>   neglected the isdn4linux subsystem in their work.

For simile changes they have kept it going (eg the tty changes), but the
code is too big and too messy for that to happen for all things. Thus
it will eventually break

> - These are two independent problems. Blocking the correction of
>   one of them because the other one still exists doesn't help,
>   but only risks deadlock.

No risk of deadlock. It'll progress to && BROKEN which will either cause
sufficient pain for someone to get off their arse and fix it, for enough
of a vendors users to get the vendor to do the work or for someone who
cares to pay a third party to do the work.

Alan

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Am 22.04.2007 14:58 schrieb Alan Cox:
>>>> If it isn't obsolete then fix the code to use the newer APIs
>> Why should that be a precondition for removing the incorrect
>> "obsolete" label?
> 
> Because if we remove the obsolete label the users are going to be
> suprised when it goes away entirely with && BROKEN or && !HOTPLUG or
> similar.

I trust that && BROKEN won't happen before it will actually *be*
obsolete and correctly re-labelled as such. As for the && !HOTPLUG
menace you keep touting, that might perhaps be applied to some of
the individual hardware device drivers but certainly not to the
I4L core itself. What you mean by "or similar" I cannot guess.
AFAIK we don't have an && EYESORE option yet. :-)

>> Any change that breaks isdn4linux before its
>> replacement is ready would constitute a regression.
>> We've been there once, remember?
> 
> Want to be on that. There is nobody maintaining it. That isn't a
> sustainable situation so it will break.

Not sure I'm following you. There is an official maintainer, and
although he's currently rather silent on this topic, there's no
reason to believe he won't step up if there's actually some urgent
maintaining to be done.

>> [L]ack of a working replacement *is* an
>> argument for concluding that something is not obsolete.
> 
> Ok then it should be marked "BROKEN" instead.

Is that a serious suggestion? Replace one wrong label with another,
even wronger one? I don't see how that might help.

>> - These are two independent problems. Blocking the correction of
>>   one of them because the other one still exists doesn't help,
>>   but only risks deadlock.
> 
> No risk of deadlock. It'll progress to && BROKEN which will either cause
> sufficient pain for someone to get off their arse and fix it, for enough
> of a vendors users to get the vendor to do the work or for someone who
> cares to pay a third party to do the work.

Do I sense some hidden agenda there?

The isdn4linux subsystem will not "progress" to BROKEN unless
somebody pushes it there. It is currently working sufficiently
well for its users to fill the gap until its successor CAPI is
ready. Once that happens, it can be obsoleted, but not before.
I know people are less than happy this hasn't happened yet, but
the way to promote the move to CAPI is not to kill off I4L before
the time and leave users standing in the rain.

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Alan Cox]

> obsolete and correctly re-labelled as such. As for the && !HOTPLUG
> menace you keep touting, that might perhaps be applied to some of
> the individual hardware device drivers but certainly not to the

In my tree its just the drivers that still use pci_find_device.

> > Want to be on that. There is nobody maintaining it. That isn't a
> > sustainable situation so it will break.
> 
> Not sure I'm following you. There is an official maintainer, and
> although he's currently rather silent on this topic, there's no
> reason to believe he won't step up if there's actually some urgent
> maintaining to be done.

Well once it ends up && BROKEN perhaps patches will appear, or before
that. If not well the pain factor will resolve the problem.

> > No risk of deadlock. It'll progress to && BROKEN which will either cause
> > sufficient pain for someone to get off their arse and fix it, for enough
> > of a vendors users to get the vendor to do the work or for someone who
> > cares to pay a third party to do the work.
> 
> Do I sense some hidden agenda there?

No I'm speaking from experience - if a subsystem maintainer is too
busy/working on other projects and the subsystem stops working it
produces a rapid and sudden supply of new maintainers, unless nobody
cares in which case it can go in the bitbucket.

> The isdn4linux subsystem will not "progress" to BROKEN unless
> somebody pushes it there. 

It has drivers using functions that will soon be deleted. That isn't so
much as pushing more like getting fed up of pulling someone elses cart
along.

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Satyam Sharma]

Hi Alan,

On 4/22/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > No risk of deadlock. It'll progress to && BROKEN which will either cause
> > > sufficient pain for someone to get off their arse and fix it, for enough
> > > of a vendors users to get the vendor to do the work or for someone who
> > > cares to pay a third party to do the work.
> >
> > Do I sense some hidden agenda there?
>
> No I'm speaking from experience - if a subsystem maintainer is too
> busy/working on other projects and the subsystem stops working it
> produces a rapid and sudden supply of new maintainers, unless nobody
> cares in which case it can go in the bitbucket.

Sorry for butting in (I have absolutely no interest or stake in I4L,
just joining in the debate to clear my understanding of how things
have always worked or should work in kernel development):

I must be missing something here. Tilman's point is really quite
simple and fundamental (which you haven't answered as yet). Why, or
rather how, were the writers of newer APIs _allowed_ to push *their*
stuff into the kernel _without_ even bothering to convert the
*existing* users of the older APIs in the kernel? This goes against
the spirit of pretty much how anything is done in here ... one can't
really find fault with the original author of I4L for not using APIs
that didn't even exist when he wrote I4L. Or was I4L always obsolete
from the beginning itself when it was merged in?

> > The isdn4linux subsystem will not "progress" to BROKEN unless
> > somebody pushes it there.
>
> It has drivers using functions that will soon be deleted. That isn't so
> much as pushing more like getting fed up of pulling someone elses cart
> along.

It's not about "pushing someone else's cart". It's about not breaking
existing (and working) kernel subsystems that do have a userbase.
Saying that some code is messy and convoluted etc etc does *not*
justify the writers of newer APIs from ignoring to update an existing
and working kernel subsystem to their newer APIs. If we allow
something like this (or if this was allowed in the past), then we
could be setting a very unfortunate precedent.

I really don't have any specific knowledge of the I4L codebase, so
perhaps you and Dave do have better reasons to keep it marked as
obsolete (and *allow* it get broken by API changes in the future).

Satyam

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Alan Cox]

> simple and fundamental (which you haven't answered as yet). Why, or
> rather how, were the writers of newer APIs _allowed_ to push *their*
> stuff into the kernel _without_ even bothering to convert the
> *existing* users of the older APIs in the kernel? This goes against

Because to convert the existing ISDN4Linux heap into the new APIs would
require someone with all the cards involved and a lot of time (as the
card drivers need a *lot* of work by now to bring them up to todays work)

> the spirit of pretty much how anything is done in here ... one can't
> really find fault with the original author of I4L for not using APIs
> that didn't even exist when he wrote I4L.

Of course not - and I4L as originally merged is very different to I4L as
it is now - both because it was maintained and because other people fixed
things when it was easy to do so (eg the tty layer changes).

> and working kernel subsystem to their newer APIs. If we allow
> something like this (or if this was allowed in the past), then we
> could be setting a very unfortunate precedent.

"Precedent", that implies it is a new behaviour - which it isn't. We
regularly break old driver code when it is neccessary in order to make
general progress. Grep for "BROKEN" in the kernel tree.

> I really don't have any specific knowledge of the I4L codebase, so
> perhaps you and Dave do have better reasons to keep it marked as
> obsolete (and *allow* it get broken by API changes in the future).

If the changes to make it use pci_get_ were trivial I'd simply have
pushed them, but they are not due to the rather bizarre structure of some
of the drivers - ditto some of the other changes.

You, and anyone else who wants to, are free to work on I4L and fix it,
improve it and make it better. 

Alan

Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]

Am 22.04.2007 17:17 schrieb Alan Cox:
> Well once it ends up && BROKEN perhaps patches will appear, or before
> that. If not well the pain factor will resolve the problem.
>
>>> No risk of deadlock. It'll progress to && BROKEN which will either cause
>>> sufficient pain for someone to get off their arse and fix it, for enough
>>> of a vendors users to get the vendor to do the work or for someone who
>>> cares to pay a third party to do the work.
>>
>> Do I sense some hidden agenda there?
> 
> No I'm speaking from experience - if a subsystem maintainer is too
> busy/working on other projects and the subsystem stops working it
> produces a rapid and sudden supply of new maintainers, unless nobody
> cares in which case it can go in the bitbucket.
> 
>> > The isdn4linux subsystem will not "progress" to BROKEN unless
>> > somebody pushes it there. 
> 
> It has drivers using functions that will soon be deleted. That isn't so
> much as pushing more like getting fed up of pulling someone elses cart
> along.

Do I understand you correctly? You deliberately want to move it
to BROKEN to cause pain in the hope of forcing somebody other than
"the person who did the kernel change in the first place" (quote
stable_api_nonsense.txt) to do the fixing up?

Am 22.04.2007 18:20 schrieb Alan Cox:
>> Why, or
>> rather how, were the writers of newer APIs _allowed_ to push *their*
>> stuff into the kernel _without_ even bothering to convert the
>> *existing* users of the older APIs in the kernel? This goes against
> 
> Because to convert the existing ISDN4Linux heap into the new APIs would
> require someone with all the cards involved and a lot of time (as the
> card drivers need a *lot* of work by now to bring them up to todays work)

Not true. None of the past kernel API changes were done by someone
who had all the hardware for the affected drivers. I have personally
acked changes to the driver I maintain from people who don't have
the hardware, and the changes were fine. The one inventing a new
kernel API to replace an old one is in the best position for actually
replacing it in the existing users of the old API, and that's also
what stable_api_nonsense.txt stipulates.

> "Precedent", that implies it is a new behaviour - which it isn't. We
> regularly break old driver code when it is neccessary in order to make
> general progress. Grep for "BROKEN" in the kernel tree.

I did grep for "BROKEN" in the 2.6.21-rc7 sources and couldn't find
an instance of a driver that was still in active use being broken in
order to make general progress. OTOH I remember several cases of
drivers being kept alive even though they were in the way of
progress, because there were still users relying on them.

> You, and anyone else who wants to, are free to work on I4L and fix it,
> improve it and make it better. 

You are turning the situation on its head. I4L works. Somebody wants
to push through a kernel API change that would break it. In every
other case I know, it was the responsibility of those doing the
kernel API change to fix the in-tree users of that API. As long as
they didn't finish that job, the old API would stay. Nobody advocates
moving reiserfs to BROKEN for still using lock_kernel(), to cite a
recent issue. So why isdn4linux?

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

[PATCH] ISDN4Linux: fix maturity label (v4)

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

Seeing that the discussion about this has ebbed out but the last version
of this patch has disappeared again from the -mm tree, permit me another
attempt to get this fixed:

From: Tilman Schmidt <tilman@imap.cc>

According to the definitions recently posted on LKML, the maturity label
for the ISDN4Linux subsystem is wrong. This patch corrects it and also
clarifies the accompanying help text a bit.

Signed-off-by: Tilman Schmidt <tilman@imap.cc>

---

--- a/drivers/isdn/Kconfig	2007-02-04 19:44:54.000000000 +0100
+++ b/drivers/isdn/Kconfig	2007-05-28 14:48:54.000000000 +0200
@@ -25,9 +25,9 @@ menu "Old ISDN4Linux"
 	depends on NET && ISDN

 config ISDN_I4L
-	tristate "Old ISDN4Linux (obsolete)"
+	tristate "Old ISDN4Linux (deprecated)"
 	---help---
-	  This driver allows you to use an ISDN-card for networking
+	  This subsystem allows you to use an ISDN adapter for networking
 	  connections and as dialin/out device.  The isdn-tty's have a built
 	  in AT-compatible modem emulator.  Network devices support autodial,
 	  channel-bundling, callback and caller-authentication without having
@@ -38,8 +38,9 @@ config ISDN_I4L

 	  ISDN support in the linux kernel is moving towards a new API,
 	  called CAPI (Common ISDN Application Programming Interface).
-	  Therefore the old ISDN4Linux layer is becoming obsolete. It is
-	  still usable, though, if you select this option.
+	  Therefore the old ISDN4Linux layer will eventually become obsolete.
+	  It is still available, though, for use with adapters that are not
+	  supported by the new CAPI subsystem yet.

 if ISDN_I4L
 source "drivers/isdn/i4l/Kconfig"

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]