[GSOC] : Unified API

[Rempel, Cynthia]

Hi Vipul Nayyar,

You're welcome :) My understanding is the documentation is out of sync with the source tree... so I looked through the git and identified some stuff...

I also know there are different approaches we want taken with different headers...

Part of the task would be to identify which headers fall into:

1. 'make private' category: don't install
2. 'relocate' category: where should we put them?
3. 'merge' category: how should we combine them? What is the standard API to implement this functionality?

A quick look indicates the headers for merging/standardizing within a cpu family may be located in c/src/lib/libbsp/*/*/include...
A place to find some headers could be standardized across cpu families may be: c/src/lib/libcpu/*/*/include

Going through the source tree, it looks like there are some cpu specific headers in cpukit/score/cpu/*, (I don't know right now if they're installed, or if they should be... I suspect most should not)

Basically, to ensure the RTEMS development community knows I will restate the current state of the headers for RTEMS...

If we could install the cpu-independent headers outside of a bsp-dependent directory, this will boil down to approx <7 headers per cpu/bsp to standardize and merge... this is probably a matter of a few tweaks in the build system... 

of course the way RTEMS installs headers leads to... the enormity of the problem consists of having approx each of the headers for the RTEMS API installed once for each of 100+ BSPs, but we would rather install a smaller number of headers... the expectation is not to completely solve the problem but reduce it.

I'll propose the following for where these headers could be installed... to reduce the number of headers installed...
Part of this task could include ensuring the headers are written in such a way as to make switching between architectures more easily (a standard API).  One way to break down where these headers should go would be:
include/
include/arch
include/arch/avr
include/arch/avrtest
include/arch/bfin
include/arch/bfin/TLL6527M
include/arch/bfin/bf537Stamp
etc.

An alternative would be to use many #ifdef / #endif

But hopefully this will help with the 'mountain of toothpicks'... we'll do our best to support you :)

We really appreciate your willingness to tackle this task!
Cynthia Rempel
________________________________________
From: Vipul Nayyar [nayyar_vipul at yahoo.com]
Sent: Wednesday, April 17, 2013 11:27 AM
To: cynt6007 at vandals.uidaho.edu; Joel Sherrill
Cc: rtems-devel at rtems.org
Subject: [GSOC] : Unified API

Hello All,

Just wanted to tell you, that I found the previous mails on Unified API from all of you quite interesting to read. After reading your views and proposed plans on this project, I'm gaining more and more enthusiasm for this 'mountain of toothpicks' task over the summer. I think I understood quite much about what you want out of this project.

But in order to work on this project, I need to understand the overall architecture of RTEMS in more detail.
Currently I'm referring to the online docs given at http://rtems.org/onlinedocs/doc-current/share/rtems/ . But I feel there are quite discrepancies present , maybe the docs don't conform to the latest version of RTEMS. So, Is there any other source containing relevant information from where I can learn ??

Once again, Thanks for your inputs and support over the past few days !!

Regards
Vipul Nayyar
Computer Engineering
Jamia Millia Islamia
New Delhi