[PATCH] bsps/sparc: Add grlib_malloc(), grlib_calloc()

[Daniel Hellstrom]

On 2018-12-21 15:12, Sebastian Huber wrote:
> On 21/12/2018 15:06, Daniel Hellstrom wrote:
>>
>> On 2018-12-21 15:02, Sebastian Huber wrote:
>>> On 21/12/2018 14:59, Daniel Hellstrom wrote:
>>>> On 2018-12-21 14:57, Sebastian Huber wrote:
>>>>> Hello Daniel,
>>>>>
>>>>> On 21/12/2018 14:42, Daniel Hellstrom wrote:
>>>>>> Hi Sebastian,
>>>>>>
>>>>>> Sorry for my very late response! I have reviewed the code but not 
>>>>>> executed it, it looks okay with me. I'm guessing it is also a 
>>>>>> positive thing to remove malloc for another approach to allocate 
>>>>>> memory when it comes to validation of the SW.
>>>>>
>>>>> thanks for the review.
>>>>>
>>>>> My next step is to move the grlib to bsps/shared/grlib so that it 
>>>>> can be used for RISC-V BSPs.
>>>>
>>>>
>>>> Great news! how will you do with the driver manager in this case, 
>>>> will you add a connection between FDT and the driver manager via 
>>>> FDT-bus driver? I think that would be of interest also for LEON, I 
>>>> would be happy to review such a solution or similar one. 
>>>
>>> Sorry, I don't have time to match the FDT with the driver manager. 
>>> The libbsd has already this functionality. All I plan to do at the 
>>> moment is to move the files and make them compile clean.
>>>
>> Okay, in the long-term do you think it is better to move to the 
>> libbsd way than using the driver manager? The driver manager is 
>> around 10k, and the required stuff around 5k on sparc if I recall 
>> correctly. Do you have an idea how large the device discovery, etc. 
>> is in libbsd?
>
> I don't have figures, but the libbsd is more for systems that provide 
> RAM in quantities of 1MiBs and not 10KiBs.

Thats my assumption too, then we will stick with the driver manager. 
However at some point we would want to add a GRETH_GBIT network driver 
for the libbsd stack, maybe it is required for that particular driver 
then, I don't know. I will have to dig into that at some point.