<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 4/14/2013 9:27 AM, Vipul Nayyar
wrote:<br>
</div>
<blockquote
cite="mid:1365949633.77645.YahooMailNeo@web194906.mail.sg3.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff; font-family:arial,
helvetica, sans-serif;font-size:10pt">
<div><span><br>
</span></div>
<div> Hello Cynthia Rempel,</div>
<div><br>
</div>
<div>As advised by you, I tried to merge header files with same
name getting installed into different places. For this task, I
chose to merge two 'syslog.h' files present in libnetworking
directory , as a starting point. After merging them and
editing other files which required this header file, I
re-compiled RTEMS successfully. I've attached two patches with
this email. Please check them if they're ok and good to be
applied. </div>
<div><br>
</div>
<div>To have an idea that how many duplicate header files are
actually present in <span style="color: rgb(69, 69, 69);
font-family: Helvetica, Arial, sans-serif; font-size:
11.818181991577148px;">/opt/rtems-4.11/sparc-rtems4.11 , I
wrote a shell script for that. The output of that bash
script is also attached with this email. As you can see in
that text file, there are quite many duplicate header files
present . Please tell me any plan or steps that I should use
to merge so many files, if possible. </span></div>
<div><span style="color: rgb(69, 69, 69); font-family:
Helvetica, Arial, sans-serif; font-size:
11.818181991577148px;"><br>
</span></div>
</div>
</blockquote>
This is part of understanding the problem. There are a variety of
reasons<br>
why there are duplicate files there. And from here, it is going to
read<br>
like a long winded explanation but this project is important but you
have<br>
to know the parameters of when to merge or rework .h files. These
rules<br>
are part of the RTEMS "folklore" and although we will cite them
individually,<br>
I doubt you will find this detailed of an explanation anywhere.<br>
<br>
(1) How are they really included (e.g. "#include <XXX.h>")?<br>
You need to realize that they likely aren't to be classified as<br>
duplicate .h files if they are included using different names.
time.h<br>
is a standard POSIX .h file <time.h> != <sys/time.h> and
the distinction<br>
is required. <machine/time.h> reflects the implementation of
the<br>
C Library and that is outside this project (or our general control).<br>
<br>
(2) target specific versions of compiler or libc provided files. A
quick<br>
check shows I have 12 files installed named "types.h". I have 6
target <br>
tool sets installed and each has <sys/types.h> and
<machine/types.h>.<br>
Sometimes these are required by standards. Sometimes it is the<br>
design of a library over which we have no control. <br>
<br>
In this case <sys/types.h> is from standards.
<machine/types.h> is the<br>
implementation details. In both cases, they are owned by another
project<br>
which trips a rule below. Either way, these are off-limits for this
project.<br>
<br>
FYI as an exercise look for limits.h in the toolset install. You
will<br>
see 5 per target. They all have a reason to exist. :)<br>
<br>
FWIW each target for which gcc/newlib is installed contains a near<br>
100% duplication of header files. This is by design.<br>
<br>
(3) code in RTEMS that ifins based on an open standard.
cpukit/posix<br>
has <semaphore.h> and <rtems/posix/semaphore.h>. Yes the
basename<br>
is the same but the contents of <semaphore.h> are POSIX
defined<br>
and our implementation details are in
<rtems/posix/semaphore.h>.<br>
You can't merge those without putting things in a .h file defined by
a<br>
standard which are not supposed to be there.<br>
<br>
FWIW .. the Classic API (e.g. cpukit/rtems) does not have this
separation<br>
of public API/types and implementation. This is on the RTEMS
wishlist<br>
as well and could be part of this effort.<br>
<br>
FYI you tripped this case as <syslog.h> is part of POSIX and
the contents<br>
defined by Open Group:<br>
<br>
<a
href="http://pubs.opengroup.org/onlinepubs/7908799/xsh/syslog.h.html">http://pubs.opengroup.org/onlinepubs/7908799/xsh/syslog.h.html</a><br>
<br>
<sys/syslog.h> is likely part of the implementation but that
leads us<br>
to the next thing to be aware of.<br>
<br>
(4) There is code in RTEMS which is from third parties.
libnetworking<br>
is the biggest lump of this. Our network code, many supporting
clients<br>
and servers, and network device drivers are from other projects like<br>
FreeBSD. These cannot be changed because they are not owned by <br>
the RTEMS Project. Changing them will make it harder to upgrade<br>
in the future.<br>
<br>
<syslog.h> and <sys/syslog.h> are part of libnetworking
which is<br>
from FreeBSD. So they are off-limits by the third party code rule.<br>
<br>
(5) Most of the duplicate <XXX.h> header files are CPU, chip,
or board<br>
specific. For examples, there are 7 .h files whose basename is
uart.h<br>
and 14 who match the pattern "*uart.h". Even though these are part<br>
of the BSP install, they are included with the same <XXX.h>
include line.<br>
That's the key part of duplicate .h files. BSPs may have their own
version<br>
of a common-ish name .h file like uart.h and install it in a way
which <br>
MAY result in "#include <XXX.h>" corresponding to two
different files <br>
in the source tree.<br>
<br>
Sometimes this is deliberate (e.g. bsp.h, bspopts.h) and other times
it is <br>
an accident which needs to be resolved. uart.h is an example of one
which<br>
needs resolving. We need a long term plan to separate really BSP
specific<br>
files from BSP files which are assumed to be there like bsp.h.<br>
<br>
The way to think about this is if you installed every BSP and then
did a find<br>
on "*.h" -- ignoring libc and gcc .h files -- how many files would
be different<br>
if you did "#include <xxx.h>" on BSP A versus BSP B. <br>
<br>
Switching gears, ... the first focus of the "unified APIs" project
is to ensure that<br>
in areas where BSP support capabilities and APIs have evolved over
the years <br>
(e.g. PCI and PIC interrupt handling), that there all code is moved
to the latest<br>
and best version of this. We want to kill older implementations and
inconsistencies<br>
across targets and BSPs. One part of this would be to generalize
the PIC interrupt<br>
support in sparc to support any other simple vectored architecture.
<br>
<br>
Ideally this would eliminate some older code which is not
recommended for use<br>
in new BSPs. I will start a separate thread for this.<br>
<br>
And on the other question.. update the TCP/IP stack.. if you know
the Rabbit<br>
in Monty Python's Holy Grail or Spamalot, then you know what to
do...<br>
<br>
****** RUN AWAY ******<br>
<br>
This project is partially complete and requires debugging. Without
deep knowledge<br>
of FreeBSD initialization and internals, network programming,
Python, and RTEMS, <br>
this is a project you want to avoid. It is a good one but unless you
have the magic set<br>
of skills, it is also likely you will not succeed. And we don't want
that.<br>
<blockquote
cite="mid:1365949633.77645.YahooMailNeo@web194906.mail.sg3.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff; font-family:arial,
helvetica, sans-serif;font-size:10pt">
<div><span style="color: rgb(69, 69, 69); font-family:
Helvetica, Arial, sans-serif; font-size:
11.818181991577148px;">Also please explain the procedure to
obtain committer access as written here : </span><a
moz-do-not-send="true"
href="http://rtems.org/wiki/index.php/Git_Committers"
style="font-size: 10pt;">http://rtems.org/wiki/index.php/Git_Committers</a><br>
</div>
</div>
</blockquote>
In general, very few people get commit privileges. Those that do
have long<br>
term associations with the project and have worked on multiple
areas.<br>
<br>
We prefer to have patches reviewed and a small number of folks who<br>
do actually commits.<br>
<br>
<br>
<blockquote
cite="mid:1365949633.77645.YahooMailNeo@web194906.mail.sg3.yahoo.com"
type="cite">
<div style="color:#000; background-color:#fff; font-family:arial,
helvetica, sans-serif;font-size:10pt">
<div>Thanks for your support in advance.</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
arial, helvetica, clean, sans-serif; background-color:
transparent; font-style: normal;"><br>
</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
arial, helvetica, clean, sans-serif; background-color:
transparent; font-style: normal;">Regards</div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
arial, helvetica, clean, sans-serif; background-color:
transparent; font-style: normal;"><span
style="background-color:transparent;line-height:1.22;">Vipul
Nayyar </span></div>
<div style="color: rgb(0, 0, 0); font-size:
12.727272033691406px; font-family: arial, helvetica, clean,
sans-serif; background-color: transparent; font-style:
normal;"><span
style="background-color:transparent;line-height:1.22;">Computer
Engineering</span></div>
<div style="color: rgb(0, 0, 0); font-size:
12.727272033691406px; font-family: arial, helvetica, clean,
sans-serif; background-color: transparent; font-style:
normal;"><span
style="background-color:transparent;line-height:1.22;">Jamia
Millia Islamia</span></div>
<div style="color: rgb(0, 0, 0); font-size:
12.727272033691406px; font-family: arial, helvetica, clean,
sans-serif; background-color: transparent; font-style:
normal;"><span
style="background-color:transparent;line-height:1.22;">New
Delhi</span></div>
<div style="color: rgb(0, 0, 0); font-size: 13px; font-family:
arial, helvetica, clean, sans-serif; background-color:
transparent; font-style: normal;"><br>
</div>
<div><br>
</div>
<div style="font-family: arial, helvetica, sans-serif;
font-size: 10pt;">
<div style="font-family: 'times new roman', 'new york', times,
serif; font-size: 12pt;">
<div class="y_msg_container"><br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985 </pre>
</body>
</html>