Re: PNP patch into kernel when?

Andrew E. Mileski (aem@ott.hookup.net)
Wed, 4 Dec 1996 23:45:00 -0500 (EST)

> > The difference is of course that we are free to fool around with
> > symbols that are internal to the kernel. We don't have this luxury
> > with malloc(). The changes in the PnP kernel patch do not affect
> > anything other than the kernel source.
>
> Well I sincerely hope Linus doesnt accept them until you realise the
> non luxury of maintaining large numbers of drivers, the linux source tree
> backward compatibility and not upsetting commercial vendors doing Linux
> drivers.
>
> Your argument was true 3 years ago. It isnt now

Alan (and others), I'm not stupid, and have no intentions to
cause Linux any harm - I'm trying to help it. It is obvious
their is strong opposition to the changes I proposed previously,
so the solution is simple - I won't do it that way :-)

I've already posted an ALTERNATIVE approach, and have gotten
one nod to go ahead. I'd like some more opinions on it,
before casting it in stone. Here it is again....

=================

Due to popular demand for backwards compatibility, the calls proposed
in the NEW hardware resource management API are:

request_hw_resource() release_hw_resource()

Management of _all_ hardware resources (DMA, IRQ, I/O, addresses, etc.)
will be handled by these two architecture independent calls.

All of the following kernel calls will be marked as deprecated,
their usage will cause a warning to be logged, and they will
invoke the above hardware resource management API to do their work,
but will otherwise be 100% compatible (binary and source):

request_region() release_region() check_region()
request_dma() free_dma()

All occurances of the above calls in the kernel will be replaced by
equivalent calls to the proposed NEW hardware resource management API.

--
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