[En-Nut-Discussion] Killing Processes and malloc

[Moritz Struebe]

Alain M. schrieb:
> Ole Reinhardt escreveu:
>   
>>> To solve this I was thinking of adding a allocated mem list for each 
>>> process. This does bring a bit of overhead but I think is't a worth that 
>>> price. The root of the list would be in NUTTHREADINFO. If a process gets 
>>> kill you just have to work along this list and free the mem. On an atmel 
>>> this will cost you 2 Bytes per process 2,5 Bytes per alloc. (I'd align 
>>> the blocks to a word and then use 16bit pointers.) (BTW: It should be 
>>> "long word" in heap.c:183)
>>>       
>> For me this sounds quite interesting. Especialy I'm interested in the
>> way you start other applications at runtime. How do you solve the
>> linking problem?
>>     
>
> There is an incremental linking in gcc, you give it your base binary elf 
> and link a new binary that call everything that is found in the base. 
> (only checked for ARM)
>
> The problem is that if *anything* changes in the base, everythng has to 
> be relinked. It would work for overlays, but for software updates it may 
> be too complex. That is because Nut is a real time executive, not an OS, 
> so there is not a fixed API for programs. Instead Nut becomes part of 
> the program.
>
> IMHO, the multi-boot aproach could be more effective.
>
> Alain
>   
I'm taking care of the "if anything changes" problem doing some 
crc32-checks. The reason why I need this is that I'm woking in WSNs and 
transmitting 22k is just too much if you can avoid it.
I'm not sure about the incremental linking, but it's probably not going 
to work. (The linked stuff must not be touched, the data section must 
not be changed (the memory is part of the heap and may contain data), etc).
The multi-boot approach is interesting but isn't reasonable on an AVR.
SOS and Contiki have a whole linker running on the node. Energy wise 
this is often more efficient then transmitting the whole image over the air.

Cheers
Morty