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

[Tilman Schmidt <tilman@imap.cc>]

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: signature.asc
Description: OpenPGP digital signature