Re: PNP patch into kernel when?

Andrew E. Mileski (
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
Linux Plug-and-Play Kernel Project
XFree86 Matrox Team