> 
>    >    Then why isn't it called splmalloc(), or something like that?
>    >    splimp() implies to me something to do with networking.
>    > 
>    > It's historical.  Changing the name would be gratuitous.
> 
>    Uh...
> 
> Reality check:
> 
> 1) What I did has a sound architectural reason behind it, and is
> completely upward compatible.

so, rearchitecting something is only allowed to change names when
renaming old, "working" functionality with something new and different?
it's not allowed to make existing functionality "clearer" in light
of the other changes going on?

"completely upward compatible"?  Does that mean "the pmax port
should have continued working as it previously did"?


> 2) What Ted proposed was change for the sake of change,

I would argue that there was merit in that change, though.  If you're
going to go renaming a few critical things, why not rename related
things to fit their new purpose?

> and the
> proposed name wasn't even valid.

fine, pick a valid name.



>    [...]
>    even though renaming it would make the fact clear that _something_
>    fundamental had changed?
> 
> 3) In fact, it would not, because the change would be in code that
> most people would never look at.

actually, yes it would have.

if you get rid of splimp, then the new thing will _not_ be confused
with the old meaning of splimp().

splimp used to block network hardware interrupts, and people assumed
that that was it's purpose (or at least, one of its primary ones).

If you remove it, and add a better-named function in its place, then
it's _quire_ clear that _something_ fundamental has changed, even if
users don't read the code that uses the new "something" -- uses of
splimp() will no longer work...




chris