On Thu, 2008-07-24 at 22:37 +0800, Herbert Xu wrote:
quoted text
> On Thu, Jul 24, 2008 at 08:11:49AM -0500, Matt Mackall wrote:
> >
> > 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 text
> > >  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.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html