any value to fixing apparent bugs in old ISDN4Linux?

$ 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

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

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: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

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

Good point.

Karsten Keil
SuSE Labs
ISDN development

Am 15.01.2007 18:29 schrieb Karsten Keil:

May I?

From: Tilman Schmidt <[email protected]>

Remove incorrect "obsolete" label from ISDN4Linux

---

@@ -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: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

From: Tilman Schmidt <[email protected]>

Remove incorrect "obsolete" label from ISDN4Linux.

---

@@ -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: [email protected]
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.

From: Tilman Schmidt <[email protected]>

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.

---

@@ -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: [email protected]
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.

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.

From: Alan Cox <[email protected]>
Date: Sat, 21 Apr 2007 21:58:44 +0100

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.

Am 22.04.2007 00:10 schrieb David Miller:

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.

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

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.

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: [email protected]
Bonn, Germany
- In theory, there is no difference between theory and practice.
  In practice, there is.

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.

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

Ok then it should be marked "BROKEN" instead.

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

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

Am 22.04.2007 14:58 schrieb Alan Cox:

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. :-)

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.

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

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: [email protected]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -

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

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

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.

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.

Hi Alan,

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?

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

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)

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).

"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.

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

Am 22.04.2007 17:17 schrieb Alan Cox:

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:

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.

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 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: [email protected]
Bonn, Germany
- Undetected errors are handled as if no error occurred. (IBM) -

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 <[email protected]>

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.

---

@@ -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: [email protected]
Bonn, Germany
In theory, there is no difference between theory and practice.
In practice, there is.