On Tue, Sep 17, 2019 at 02:31:34PM +0900, Park Ju Hyung wrote: > On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said: > > I'm working off a somewhat cleaned up copy of Samsung's original driver, > > because that's what I had knowledge of. If the sdfat driver is closer to being > > mergeable, I'd not object if that got merged instead. > > Greg, as Valdis mentioned here, the staging tree driver is just another exFAT fork > from Samsung. > What's the point of using a much older driver? It's the fact that it actually was in a form that could be merged, no one has done that with the sdfat code :) > sdFAT is clearly more matured and been put into more recent production softwares. > And as I wrote in previous email, it does include some real fixes. What fixes? That's what I'm asking here. How do we "know" that this is better than what we currently have today? We don't, so it's a bit hard to tell someone, "delete the work you did and replace it with this other random chunk of code, causing you a bunch more work in the process for no specific reason other than it looks 'newer'." :( > As Namjae said too, Samsung would be more interested in merging sdFAT to upstream. > If we diverge, Samsung will have less reasons to contribute their patches to upstream. Are they going to do this if we do take the sdfat code? If so, great, but I need to get someone to agree that this will happen. > Also, I think it makes much more sense to make Samsung the maintainer of this driver > (if they're willing to put in the manpower to do so). Asking them would be the first > step in doing so. They are more than willing to start contributing and being a co-maintainer of it, it needs all the help it can get. But "someone" from samsung, or anywhere else, has to be willing to step up here and do this work. Without that happening, I don't see a reason to change at this point in time. Rembember, kernel development happens because people do the work, which Valdis did, and continues to do. Throwing that away because of the thought that someone else might do some work in the future is not how we work. I recommend looking at what we have in the tree now, and seeing what is missing compared to "sdfat". I know a lot of places in the exfat code that needs to be fixed up, odds are they are the same stuff that needs to be resolved in sdfat as well. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
