Re: [S1mp3-devel] Re: New ideas for the kernel

[Legolas <leg...@em...>]

Jeroen Domburg ha scritto:

> Legolas wrote:
>
>>> but I think even then we could do without ASCII function identifiers in
>>> RAM by just looking them up on the NAND again.
>>
>>
>> Sorry but I didn't understand the above :(
>
>
> Basically, if the lib isn't in memory yet, we link it and load it in 
> memory,

Excuse me, but first we load it into memory, then we link it...or we do 
it in a hybrid way.

> so we have a large binary blob of machine code inthere. Program runs, 
> everything is fine. Then, a second program wants to run and has to 
> link itself to the lib. Problem, cause we've stripped the ascii 
> function names already. But we can always look them up in the lib 
> file, which still resides on nand, so we can link to the binary blob 
> anyway.

My proposal was, instead, to have a managed modules/functions table and 
each "incoming" program (or program module) references those constant ids.

>
>
>>> We could do the linking and fixing when we read the files from the 
>>> flash, imo. I don't think the usability suffers much if e.g. the 
>>> loading of an ap takes e.g. half a second.
>>
>>
>> Points of view.
>
>
> True, but because it's not a rationa argument, we can keep discussing 
> it without getting anywhere.
>
> Perhaps the discussions about multitasking, linked libs etc still is 
> too vague with our current knowledge of hardware. Could it be a better 
> idea to just let it float undecided for now, develop the API and 
> compile the core+libs+ap-to-be-tested into one large binary for now? 
> That way, we can proceed with the api developement and implement the 
> library loading thingie plus any multitasking as soon as we have a bit 
> more feeling with the hardware.

Hey, they told me to let it bound and that's what I have been 
doing...expressing my ideas. I do not pretend to solve it before we have 
real API code :)

> Or do you feel there's too much that the developers must change in 
> their code if we want to implement the dynamic loading thing?

No, it is a higher level issue anyway. The current development target is 
the low-level hardware abstraction layer.

>
> Jeroen

--
  Legolas