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 <>< --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to email@example.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---