Re: PNP patch into kernel when?

Philip Blundell (pjb27@cam.ac.uk)
Thu, 5 Dec 1996 03:29:15 +0000 (GMT)


On Tue, 3 Dec 1996, Andrew E. Mileski wrote:

> Here is one other solution I'm willing to accept:
>
> 1) All of the following become deprecated:
> request_region() release_region() check_region()
> request_dma() free_dma()
> No architecture can use them anymore.
>
> 2) Stubs for the above can stay in the kernel as long as required.
> Use of these stubs will produce a warning message, to
> encourage people to pester the developers to change.
> This will _ONLY_ affect separately maintained modules!
>
> 3) __ALL__ references to the old API in the kernel will be removed,
> and replaced with the equivalent request_hw_resource() or
> release_hw_resource() calls.
>
> Note: The PnP kernel patch originally used this approach, so going
> back to it is possible (it is a lot of work though, and a pain
> to maintain in parallel to the kernel source).
>
> What does everyone think?

I think I would be happy with that approach. I'd really rather you
resisted the temptation to have the old calls spit out a warning message.
Can you envisage a situation in which these old calls would _have_ to
be removed suddenly at some future date? I think developers should be
given some grace period before being harrassed, so there should be at
least one stable kernel release that supports both APIs happily.

I'm not utterly convinced that suddenly changing _all_ references to the
old calls to the new ones in one mammoth patch is necessarily desirable
either, though I don't feel very strongly about it. My instinct would be
to maybe change a few, and then leave the rest up to their respective
authors to deal with when they next update the code. Any that are still
unfixed when 2.1 gets near the end of its development cycle could be
chased then, if you wanted.

phil