[GSOC] Unified APIs Project

Gedare Bloom gedare at rtems.org
Tue Jun 4 13:11:54 UTC 2013


Does the one true way include linker scripts?

On Mon, Jun 3, 2013 at 11:39 PM, Joel Sherrill
<Joel.Sherrill at oarcorp.com> wrote:
> I want to focus first on "The One True Way" a BSP is supposed to do things, automate detecting violations, and fix as much as we can. Start with interrupt and PCI.. move on to things like does the BSP have reset and is it on the expected filename?
>
> A by product of this work should be more rules and checks for them.
>
> "Rempel, Cynthia" <cynt6007 at vandals.uidaho.edu> wrote:
>
>
>>________________________________________
>>From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Matt Wette [mwette at alumni.caltech.edu]
>>Sent: Monday, June 03, 2013 5:28 PM
>>To: rtems-devel at rtems.org
>>Subject: Re: [GSOC] Unified APIs Project
>>
>>Is there any interest in a "syscall" API that would allow future expansion into supporting "protected regions" of code?
>
> Thank you for taking an interest in the Unified API project!
>
> We could make adding a "syscall" API another open project on:
> http://www.rtems.org/wiki/index.php/Open_Projects
>
> We would probably want to concentrate on well-used, properly licensed for deeply embedded applications, syscall API (such as syscalls.master from BSD.)
>
>>>On Jun 3, 2013, at 10:15 AM, Vipul Nayyar wrote:
>>>Hello,
>>>
>>>Being accepted into GSOC with RTEMS is very exciting. This has been possible due to the constant support of Joel & Cynthia. A special >>thanks to Gedare for an in depth criticization of my proposal, which helped me improve it.
>>>
>>>I'll be working this summer on the 'Unified APIs' Project. The main task required for this project is to ensure that in areas where BSP
>>>support capabilities and APIs have evolved over the years, all the code there is moved to the latest version and any older
>>>implementations and inconsistencies across targets and BSPs are killed. The various components of this project are :
>>>
>>>  *   Generalize the PIC interrupt support in sparc to support any other simple vectored architecture.
>>>  *   Spot discrepancies in file usage in various BSPs with PCI support.
>>>  *   Review/Cleanup header files, which are publicly installed by different BSPs , since this is the area having the most variation in coding style.
>>>  *   Unify naming styles, used for the same files in different BSPs, so as to have consistent file names for the same supporting capability.
>>>My full length proposal can be found at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/vipulnayyar/1 , and >>https://docs.google.com/document/d/1oDp4E9_Wof4wBJaMJJIFoPqtu5fbTdsKwEcz-5qkazw/edit?usp=sharing
>>>As suggested by my mentor, I believe community input would act as an integral part of my work. So, I'm looking forward enthusiastically to working with you guys.
>>>Hoping for a great Summer !!!
>>>Regards
>>>Vipul Nayyar
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel



More information about the devel mailing list