On Tue, 14 Jun 2011, Michal Nazarewicz wrote: > > On Tue, Jun 14, 2011 at 08:19:53AM +0200, Michal Nazarewicz wrote: > >> With all due respect Alan, I think that in the long run we should get > >> rid of g_file_storage. Your request not to delete it when I introduced > >> g_mass_storage was a good one as it in fact turned out that > >> g_mass_storage introduced a few bugs, but as g_mass_storage matures > >> I think there is no need for g_file_storage. And I'm not saying the > >> moment is now. > > On Tue, 14 Jun 2011 09:28:11 +0200, Felipe Balbi <balbi@xxxxxx> wrote: > > Considering g_file_storage was in the tree much earlier, I'm not sure > > this is the right answer. We will loose the great contributions Alan has > > made, but OTOH we don't need two drivers doing the same thing. > > It's not that g_mass_storage was written from scratch. Most of the code > was taken from g_file_storage. I always thought about it as adding a > tiny layer to what Alan has written. I also always felt that > g_mass_storage > âis mineâ not because I wrote it but because I introduced bugs to Alan's > code, so I need to take care of those. ;) That's right; this isn't a matter of ownership. However there are some technical differences too. IIRC: g_mass_storage is more permissive about some of the module parameters. It allows "removable" and "cdrom" attributes to be specified independently for different LUNs, whereas g_file_storage uses a single value of each for all LUNs. g_file_storage allows the user to specify the transport and protocol values, whereas g_mass_storage doesn't. This is not very useful in production (everybody uses Bulk-Only and Transparent SCSI these days), but it might be useful for testing (or for emulating a USB floppy drive). In addition there's the user problem. If we eliminate one driver or the other, it forces some people to change their runtime environment. Of course, the kernel has done this sort of thing in the past. But at least there ought to be an initial period during which one driver is deprecated, before it is removed completely. > But we need to look at the facts and if we don't want two drivers doing > the same thing one needs to go away. At the same time we need a mass > storage composite function (that is f_mass_storage), which is the core > of g_mass_storage, as it's used by other gadgets as well (some out of > tree like Android). > > We could drop f_mass_storage and g_mass_storage but then we'd have to > repeat work I did by converting g_file_storage to use composite > framework. We could phase out only g_mass_storage leaving > f_mass_storage (which I have personally nothing against) but that > would not solve the issue as g_file_storage would share functionality > with f_mass_storage. So the only other option is to phase out > g_file_storage. > > Again, I'm not saying that we need to do it now but once we agree > that g_mass_storage has the same level of maturity we should, in > my opinion, phase out g_file_storage. That is, of course, if we > mind having two drivers doing the same thing (I consider it a minor > inconvenience only). I don't mind dropping g_file_storage. I haven't used the other transports or protocols for a long time. On the other hand, there may be people who do want to use them -- it's hard to know. Any ideas? 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
