On 10/20/15 1:10 PM, Tom Rini wrote:
On Tue, Oct 20, 2015 at 12:57:32PM -0600, Stephen Warren wrote:
On 10/02/2015 12:06 AM, Stephen Warren wrote:
Enhance f_read() to find the maximum contiguous set of clusters to read, and read it all at once (which is fast) rather one by one (which is slow).
Hmm. I had hoped that the author of ff.c would accept this patch upstream, so we could pick up a later upstream version that included this patch. However, it seems the author of ff.c has a policy of not accepting outside contributions:
http://elm-chan.org/fsw/ff/bd/?show=2472 (That's a link to the author's reply to my patch, on the forum system associated with his/her SW)
The bit about the license is at http://elm-chan.org/fsw/ff/en/appnote.html#license
I wonder how much of a liability incorporating ff.c into U-Boot will be, if we can't ever get any fixes merged upstream. Perhaps we just fork it, although I had hoped we'd be able to keep picking up new versions.
Arg, that really does take away one of the potential nice features. I guess, sadly, at this point I'd rather stick with the version we have unless you want to deal with re-syncing their releases but still effectively doing a fork (so that we can also make use of caches which I think you said before you thought might be part of the performance problem.
Or we take a look at borrowing the kernel's code, similar to how we leverage UBIFS today.
Regardless, thanks for the time you've already put in on this!
If anyone is still interested in replacing the FAT code, I just noticed that FreeRTOS has been relicensed to MIT along with some/all of its extensions, including the FAT code:
https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_FAT/index.html
I'd assume that code is reasonably well maintained and embedded-suitable. I have not investigated:
- If it has the same "no contributions" issue that FF had. - If it's modular enough to plug into other hosts besides FreeRTOS. - What its performance is like.