Re: [RFC 0/2] new kfifo API

[Arnd Bergmann <arnd@arndb.de>]

On Monday 03 August 2009, Stefani Seibold wrote:
> Am Montag, den 03.08.2009, 16:42 +0200 schrieb Arnd Bergmann:
> > My guess is that more importantly
> > 
> > - few people so far needed the functionality.
> 
> This is not true, that is only your view. Don't speak for other people.
> A lot of device driver developer has its own implement of a fifo. I have
> written a lot of device drivers for embedded system and i always missed
> a clean designed and implemented fifo API subsystem.

As I said, I was only guessing from the only evidence we both had, which
is the current use in the kernel. Your extrapolation was that it did
not get used much because of the quality of the existing API, my
extrapolation was that there is no need for it (at least I was
never looking for it in any of my drivers).

> > This sounds all nice, and your code looks clean and usable, but really,
> > what's your point?
> > 
> > If you have a new driver that will use all the new features, please
> > just tell us, that would make your point much clearer. Also, if
> > you can quantify an advantage (xxxx bytes code size reduce, yy%
> > performance improvement on Y benchmark) that would be really
> > helpful.
> > 
> 
> Yes, i have some drivers where i use a former version of the kfifo API.
> But the real advantage is not benchmarking.
>
> First if we have a useable kfifo API i think other developer will use
> it. And this will save memory.

Being able to simplify code is obviously good, but the normal
approach of doing it is to make it obvious in what ways. Exchanging
a whole API at once makes it unobvious what changes you do for which
purpose. 

If you split out every logical change into a separate patch,
you can easily show how to subsequently make use of that.
That also avoids the problem of adding functions that end up
being unused.

Submitting patches would also make it easier to review than
a rewrite.

> Third: The old API did not have a kfifo_to_user oder a kfifo_from_user
> functionality, so everybody wo need to store userspace data must write
> it own version of this.

That sounds like a feature that can be easily separated from the
incompatible API changes.

> Fourth: We don't discus about a havy API change, it is more subtle. And
> it doesn't blow up the kernel, okay, a little little bit. But i am sure
> that this well be gained back, if/when developer use this new API.    

Can you separate the incompatible API changes from the compatible
extensions?

	Arnd <><