Cc: Pekka Enberg <penberg@...>, Patrick McHardy <kaber@...>, Ingo Molnar <mingo@...>, David Miller <davem@...>, <w@...>, <davidn@...>, <torvalds@...>, <akpm@...>, <netdev@...>, <linux-kernel@...>, <stefanr@...>, <rjw@...>, <ilpo.jarvinen@...>, Dave Jones <davej@...>, Christoph Lameter <cl@...>
On Thu, 2008-07-24 at 22:37 +0800, Herbert Xu wrote:
Let's try this again: did you know that ksize could fail depending on
kernel configuration? Most of us would answer no. That suggests the API
is bad. This ranks 12 on Rusty's spectrum of user-friendly APIs:
http://ozlabs.org/~rusty/ols-2003-keynote/img51.html
Ahh. I see what you're saying. You may be right about that, or you may
be wrong: I don't know which of the millions of mass market embedded
Linux devices out there are using it.
And of course I argue that SLOB did do the right thing, which was only
allowing ksize on kmalloced objects. It's an accident of implementation
that kmalloc and kmem_cache_alloc use the same underlying allocator. It
has not been true at all points in the past, it's not true for some
users in the present, and it may not be true for most users in the
future. Thus, it's a bad idea to try to use ksize on something that
wasn't kmalloced.
If you have an argument for reintroducing ksize based on an actual use
case, let's please move on to (or back to) it so that we can have some
substance to this discussion.
--
Mathematics is the supreme nostalgia of our time.
--
