On Mon, 17 Aug 2009, [utf-8] MichaÅ? Nazarewicz wrote: > On Fri, 14 Aug 2009 21:23:46 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > I don't like the approach taken in these two patches. You should leave > > the existing file_storage.c alone and create new source files for the > > composite version of the driver. > > Do you think it's a better approach? My line of thinking was that there is > no point in keeping two gadgets which do the same work and thus maintaining > two copies of similar (but in many cases not identical) code. I believe this is the way other gadget drivers have been written. > In particular, are there any big drawbacks of using composite framework? If The biggest drawback to doing things your way is that you'll be removing a driver that works and is stable, replacing it with code that is not nearly as well tested. Sometimes this is necessary, but it's not necessary here. > no then IMO it'll be better to have all gadgets made using it (as then > creating composite gadgets would be somehow trivial) instead of maintaining > some gadgets in either of the two versions and some in both. The composite framework does add some overhead. In a memory-limited embedded setting, people may prefer to use the non-composite drivers. > > And on top of everything else, you based your work on an old version of > > file_storage.c. I hope you'll redo it based on the current version. > > I did? O_o And all this time I thought I was working on code from 2.6.30. > I'll look into it. 2.6.30 is not the most recent version. The most recent version is the current development kernel plus the gregkh-all patch at http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
