<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>