[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070422172017.52f21a90@the-village.bc.nu>
Date: Sun, 22 Apr 2007 17:20:17 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: "Satyam Sharma" <satyam.sharma@...il.com>
Cc: "Tilman Schmidt" <tilman@...p.cc>,
"David Miller" <davem@...emloft.net>, linux-kernel@...r.kernel.org,
kkeil@...e.de, i4ldeveloper@...tserv.isdn4linux.de,
akpm@...ux-foundation.org
Subject: Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists