> 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.
We aren't free to fool around with those symbols. We _are_ free to
arbitrarily rename some symbols that truly are internal to the kernel (for
example, if you wanted to rename 'adapter_reset' in the 3c505 driver to
'reset_card' then I doubt anybody would be too upset). But an awful lot
of the symbols in the kernel constitute a programming interface. This is
true both because the kernel source is maintained by an awful lot of
different people, who have a reasonable right to expect things outside
'their patch' to stay the same, and because there is a substantial body of
code out there that, although not distributed with the kernel, still has
to interwork with it. This means things like Stephen's supermount patch,
or third-party hardware drivers.
I have a collection of drivers and things that deal with bizarre and
proprietary hardware of some sort or another, and neither I nor the people
who pay me to write them particularly relish the thought of having to have
them altered to work with new kernels on a regular basis. If they relied
on some particular deep magic to do with the implementation details of the
bowels of the kernel, then I'd be prepared to see them break, but not if
they stick to what I consider to be clean and legal interfaces. Your
assertion that the PnP patches 'do not affect anything other than the
kernel source' is simply false, unless you expand your definition of 'the
kernel source' to mean 'the kernel source, and everything that works with
it'.
IMHO, any symbol that gets exported to modules should be viewed as
'external', and not changed without a very good reason. This applies
especially to global things like kmalloc and the request_*() functions.
phil