Re: PNP patch into kernel when?

Andrew E. Mileski (
Tue, 3 Dec 1996 16:12:40 -0500 (EST)

> > I expect to have the bulk of it (resource management) put into a v2.1.*
> > kernel, when it has been debugged and tested enough. This will change
> > a lot of code in the existing kernel (some common calls have been renamed),
> > so it will likely have to be in its own kernel patch. Kernel developers
> > will have to sync their working code to the new patched kernel.
> What exactly is the benefit of renaming request_region() and so on? As
> far as I can see, this is just going to break an awful lot of perfectly
> good code for no real purpose.

The renaming is to make the internal kernel API common to all
hardware resources. Renaming stuff internal to the kernel
doesn't break anything, except 3rd party modules. Breaking
stuff for a better kernel is okay, especially in an experimental
kernel :*)

These two handle regions for I/O, IRQ, DMA, and addresses:
It would have be easy to change everything to use these,
but for simplicity, a number of wrappers have been provided.

These are derived from the above:
request_address() release_address()
request_dma() release_dma()
request_io() release_io()
request_irq() release_irq()
Simple, logical, and compatible with the "old" calls, except all
these have a useful return value.

These have be renamed:
request_region() -> request_io()
check_region() -> check_io() *this call is unnecessary now
free_dma() -> release_dma()
request_irq() -> request_interrupt()
free_irq() -> release_interrupt()

> If the ANSI people were to decide
> tomorrow "we don't like the name 'malloc()' any more - everybody should
> change their code to use 'allocate_memory()' instead" then it wouldn't go
> down too well, and renaming core kernel functions like these is, IMHO,
> much the same.

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.

With this being so, there is a good reason to do the changes, and
no good reason not to do them :-)

Andrew E. Mileski
Linux Plug-and-Play Kernel Project
XFree86 Matrox Team