Misusing libgloss?

[Joel Sherrill]

On November 5, 2014 2:22:23 AM CST, Stefan Wallentowitz <stefan.wallentowitz@tum.de> wrote:
>Hi again,
>
>I have another general question about libgloss and the upstream 
>policies. I have spend some time now changing the license and rewriting
>
>code for the OpenRISC port as we want to get it upstream now (it was
>GPL 
>before).

The OpenRISC code in newlib now is more than sufficient to support RTEMS. And it avoided the GPL mess.

Unless you are adding machine specific optimized routines like string or memory functions, they need to go in libgloss. The machine directory is shared by bare metal, RTEMS, Linux, and any other OS.

>The old OpenRISC port had some support functions in the newlib machine 
>directory, like handling the CPU's MMU, caches and timer (see [1]). It 
>also had the functionality to register C hooks for exceptions and 
>external interrupts, something I find neat and want to preserve.
> From what I understood all this functionality is not really something 
>that should be put in the newlib machine directory, but is better
>suited 
>in libgloss. Is that correct? Now I have all those functions in
>libgloss 

That is right technically and I am OK with it being merged but I am not the final word.

>[2]. I have seen some stuff like this in other architectures (like 
>sparc_leon), but maybe not to the same extent. So, long story short: 
>Does this have a chance to be accepted for upstream?
>
>Thansk for your help, I hope I can also stop those questions soonly.
>
>Best regards,
>Stefan
>
>[1] 
>https://github.com/openrisc/or1k-src/blob/or1k/newlib/libc/machine/or1k/include/or1k-support.h
>[2] https://github.com/wallento/or1k-newlib/tree/master/libgloss/or1k