> 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. Granted, the current names may not be
precisely the best, but there's nothing very wrong with them and I think
changing them now would just antagonise people who are trying to maintain
compatibility with the kernel code. 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.
phil