Messages in this thread |  | | Subject | Re: PNP patch into kernel when? | Date | Tue, 3 Dec 1996 16:12:40 -0500 (EST) | From | "Andrew E. Mileski" <> |
| |
> > 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: request_hw_region() release_hw_region() 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 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
|  |