On Thu, 2008-07-24 at 22:37 +0800, Herbert Xu wrote:

On Thu, Jul 24, 2008 at 08:11:49AM -0500, Matt Mackall wrote:

quoted

You don't honestly expect people to correctly code to such a standard,
do you? People will assume that ksize never fails, they will be wrong,
and computers will die.

If we follow this argument then most of our interfaces would be
broken.

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

quoted

quoted

 You're taking
away an entire interface just because an underlying implementation
that's used by a very small proportion of users doesn't do the
right thing.

Umm, no. There were very few users to being with, so it was actually a
fairly large proportion. And that suggested the interface was a bad
idea.

Huh? I'm talking about users of the kernel.  A very small proportion
of those use SLOB.

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.