RTEMS and Google Summer of Code 2007

[Joel Sherrill]

Pavel Pisa wrote:
> Hello Joel,
>
> please, can you elaborate demands of next task a little more.
>
> | Reimplement Classic API notepads and POSIX keys using code like
> | std::map but in C. I think an implementation of the map code is
> | available under an appropriate license as a starting point.  
>
> What do you think "std::map" should be based on?
> Hash, AVL, RB-tree? If you accept AVL, I would like to integrate
> something like my uLUt's GAVL into RTEMS core to allow prepare
> high resolution (tickless) timers queues and other things. I still
> see as most important problem to decide, how to chose names
> of the functions and macros to not pollute namespace of user
> applications and to decide, if porting of these algorithms worth
> or not to be done at all and if full version or shrunk/specialized
> one should be used. Please, can you provide your opinion there.
>
>   
I had found a C implementation of a std:map at sourceforge which had
appropriate BSD license.  I must have it bookmarked on another computer.

I think it might have been linked to by 
http://en.wikipedia.org/wiki/Hash_table.

I had not done any technical evaluation of implementations.  My goal was
to find one that appropriately licensed and of reasonable algorithmic
complexity.  My first two uses were to reimplement Classic API notepads
so the block of 64 bytes are not allocated until used and to reimplement
pthread keys directly on top of the map.  Thread IDs or TCB pointers are
the unique key.

If the code is going to go in the RTEMS SuperCore, the naming conventions
are clear.  _Package_name_Method and Package_name_Data_type.  So
something like _Map_Insert or _Map_Lookup.  I don't know how an 
implementation
in C will make it look like a C++ template. 

The C++ std::map would result in an implementation of notepads and 
pthread keys
which would make me happier so that was my sole goal and intended use.

> I cannot apply for SoC and I cannot even promise for sure,
> that I find the time to work on this. But I would be happy
> if I could help there one day and if my work could be usesfull
> to others.
>   

For those concerned about what mentoring will require, I really don't know.
I believe most of the investment will be in getting their development 
system
using a simulator BSP target.  If developing on Linux, we know that yum
goes a long way to helping out here.

> I am convinced still, that uLUt is not so bad replacement
> of some STL subset for old poor C.
>   
What's the license?  I am not sold on an implementation yet. :-)

--joel


> But may it be, that I am wrong there.
>
> The other tasks, which I see as interresting, are 
> integration of Miguel Masmano's TLSF memory allocator
> and may it be finishing of Martin Molnar's work
> on EDF scheduler. But again, I do not expect, that
> original authors would find time to apply for SoC.
>
> Best wishes
>
>             Pavel Pisa
>   
ZZ