Re: PNP patch into kernel when?

Andrew E. Mileski (aem@ott.hookup.net)
Tue, 3 Dec 1996 20:06:46 -0500 (EST)

> There are at least some kernel level drivers around that didn't find their
> way into the kernel. All these must be mantained too :-(
>
> Can we do it like that:
> Introduce the new symbols. Make the old symbols some macros to call the new
> code the way we like it. Request everybody to use the new symbols. Introduce
> with 2.3 some warning message for the macros. Perhaps introduce some error
> message with 2.5 and reject the module. And with 2.7 we could delete the
> macros.

So you suggest we carry along _TWO_ compatible sets of calls,
and hope someday people use the right set, and don't mix them?
I don't think this is a good idea.

Thanks to some of the drivers using pointers to some of the calls
(like request_region), macros can't expand to anything more than
a differnet name - this is very limiting.

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?

--
Andrew E. Mileski   mailto:aem@ott.hookup.net
Linux Plug-and-Play Kernel Project http://www.redhat.com/linux-info/pnp/
XFree86 Matrox Team http://www.bf.rmit.edu.au/~ajv/xf86-matrox.html