LKML Archive on
help / color / mirror / Atom feed
From: "Satyam Sharma" <>
To: "Alan Cox" <>
Cc: "Tilman Schmidt" <>,
	"David Miller" <>,,,,
Subject: Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)
Date: Sun, 22 Apr 2007 21:18:36 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Alan,

On 4/22/07, Alan Cox <> 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).


  reply	other threads:[~2007-04-22 15:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15 11:43 any value to fixing apparent bugs in old ISDN4Linux? Robert P. J. Day
2007-01-15 13:57 ` Karsten Keil
2007-01-15 17:09 ` Tilman Schmidt
2007-01-15 17:17   ` Robert P. J. Day
2007-01-15 17:29     ` Karsten Keil
2007-02-21  0:29       ` [PATCH] Remove "obsolete" label from ISDN4Linux (was: any value to fixing apparent bugs in old ISDN4Linux?) Tilman Schmidt
2007-03-28 22:18       ` [Repost][PATCH] Remove "obsolete" label from ISDN4Linux Tilman Schmidt
2007-04-21 13:07       ` [PATCH] Remove "obsolete" label from ISDN4Linux (v3) Tilman Schmidt
2007-04-21 20:58         ` Alan Cox
2007-04-21 22:10           ` David Miller
2007-04-22 12:27             ` Tilman Schmidt
2007-04-22 12:58               ` Alan Cox
2007-04-22 14:29                 ` Tilman Schmidt
2007-04-22 15:17                   ` Alan Cox
2007-04-22 15:48                     ` Satyam Sharma [this message]
2007-04-22 16:20                       ` Alan Cox
2007-04-23 23:58                         ` Tilman Schmidt
2007-05-28 16:32       ` [PATCH] ISDN4Linux: fix maturity label (v4) Tilman Schmidt

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).