On 08/04/2016 05:12 PM, Chin Liang See wrote: > On Thu, 2016-08-04 at 07:30 +0200, Marek Vasut wrote: >> On 08/03/2016 05:22 PM, Chin Liang See wrote: >> >> Hi, > > Hi Marek, > >> >> [...] >>>>> It's the fat driver which is utilizing the malloc. >>>> >>>> So fat is allocating stuff without freeing it ? I wonder if we >>>> should >>>> either fix fat or use full malloc in SPL on A10 . I am not really >>>> fond >>>> of adding more stuff into simple malloc (to keep it small and >>>> simple). >>> >>> Actually fat driver is good where it invoke malloc and free during >>> the >>> operation. Just that with existing malloc, there is no free >>> implementation and memory keep "push" every time malloc invoked. >> >> And I agree with Simon that we should look into the FAT driver and >> fix >> it. Is that not possible ? > > > Definitely as seems everyone believe this should be the right way to > go.
Indeed >> >>>>>> Your design breaks in the scenario where someone does big >>>>>> malloc >>>>>> followed by two small mallocs if I understand it correctly. >>>>>> This >>>>>> doesn't scale and is a hack. >>>>>> >>>>> >>>>> Actually the proposed free is a simple implementation which >>>>> acts as >>>>> stack push and pop with depth of 2. This is to enhance existing >>>>> implementation which don't handle the pop. This get worst >>>>> especially >>>>> dealing with fat driver. >>>> >>>> Well, how does it handle my example? It doesn't and it fails to >>>> help >>>> in >>>> such case, right ? >>> >>> I was thinking what is the correct depth while trying to keep >>> things >>> simple. From the FAT access testing with SD and eMMC, depth of 2 >>> works >>> well by cutting lot of memory consumption by simple malloc >>> implementation. Any thoughts whether should have more flexibility? >> >> You still didn't answer my question -- how will this handle my >> example >> usecase ? >> > > I did and wonder my email server having issue again. For this case, > yah, it will not being handle as we try to keep it simple by having > depth of 2. FYI, the 2 is being derived from my experiment of FAT > driver access with SD and eMMC devices. We can enhance that but > probably that might not a good idea per Simon suggested. How would you enhance it such that I cannot find counter-example ? :) -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot