Hi Alan,
On 4/22/07, Alan Cox <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
