[GSOC] : Patches for merging different syslog.h

Sun Apr 14 17:25:52 UTC 2013

On 4/14/2013 9:27 AM, Vipul Nayyar wrote:
>
>  Hello Cynthia Rempel,
>
> 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.
>
> To have an idea that how many duplicate header files are actually 
> present in /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.
>
This is part of understanding the problem.  There are a variety of reasons
why there are duplicate files there. And from here, it is going to read
like a long winded explanation but this project is important but you have
to know the parameters of when to merge or rework .h files. These rules
are part of the RTEMS "folklore" and although we will cite them 
individually,
I doubt you will find this detailed of an explanation anywhere.

(1) How are they really included (e.g. "#include <XXX.h>")?
You need to realize that they likely aren't to be classified as
duplicate .h files if they are included using different names. time.h
is a standard POSIX .h file <time.h> != <sys/time.h> and the distinction
is required. <machine/time.h> reflects the implementation of the
C Library and that is outside this project (or our general control).

(2) target specific versions of compiler or libc provided files.  A quick
check shows I have 12 files installed named "types.h".  I have 6 target
tool sets installed and each has <sys/types.h> and <machine/types.h>.
Sometimes these are required by standards. Sometimes it is the
design of a library over which we have no control.

In this case <sys/types.h> is from standards. <machine/types.h> is the
implementation details. In both cases, they are owned by another project
which trips a rule below. Either way, these are off-limits for this project.

FYI as an exercise look for limits.h in the toolset install.  You will
see 5 per target.  They all have a reason to exist. :)

FWIW each target for which gcc/newlib is installed contains a near
100% duplication of header files. This is by design.

(3) code in RTEMS that ifins based on an open standard. cpukit/posix
has <semaphore.h> and <rtems/posix/semaphore.h>. Yes the basename
is the same but the contents of <semaphore.h>  are POSIX defined
and our implementation details are in <rtems/posix/semaphore.h>.
You can't merge those without putting things in a .h file defined by a
standard which are not supposed to be there.

FWIW .. the Classic API (e.g. cpukit/rtems) does not have this separation
of public API/types and implementation. This is on the RTEMS wishlist
as well and could be part of this effort.

FYI you tripped this case as <syslog.h> is part of POSIX and the contents
defined by Open Group:

http://pubs.opengroup.org/onlinepubs/7908799/xsh/syslog.h.html

<sys/syslog.h> is likely part of the implementation but that leads us
to the next thing to be aware of.

(4) There is code in RTEMS which is from third parties. libnetworking
is the biggest lump of this. Our network code, many supporting clients
and servers, and network device drivers are from other projects like
FreeBSD. These cannot be changed because they are not owned by
the RTEMS Project. Changing them will make it harder to upgrade
in the future.

<syslog.h> and <sys/syslog.h> are part of libnetworking which is
from FreeBSD. So they are off-limits by the third party code rule.

(5) Most of the duplicate <XXX.h> header files are CPU, chip, or board
specific. For examples, there are 7 .h files whose basename is uart.h
and 14 who match the pattern "*uart.h". Even though these are part
of the BSP install, they are included with the same <XXX.h> include line.
That's the key part of duplicate .h files.  BSPs may have their own version
of a common-ish name .h file like uart.h and install it in  a way which
MAY result in "#include <XXX.h>" corresponding to two different files
in the source tree.

Sometimes this is deliberate (e.g. bsp.h, bspopts.h) and other times it is
an accident which needs to be resolved. uart.h is an example of one which
needs resolving. We need a long term plan to separate really BSP specific
files from BSP files which are assumed to be there like bsp.h.

The way to think about this is if you installed every BSP and then did a 
find
on "*.h" -- ignoring libc and gcc .h files -- how many files would be 
different
if you did "#include <xxx.h>" on BSP A versus BSP B.

Switching gears, ... the first focus of the "unified APIs" project is to 
ensure that
in areas where BSP support capabilities and APIs have evolved over the 
years
(e.g. PCI and PIC interrupt  handling), that there all code is moved to 
the latest
and best version of this. We want to kill older implementations and 
inconsistencies
across targets and BSPs.  One part of this would be to generalize the 
PIC interrupt
support in sparc to support any other simple vectored architecture.

Ideally this would eliminate some older code which is not recommended 
for use
in new BSPs. I will start a separate thread for this.

And on the other question.. update the TCP/IP stack.. if you know the Rabbit
in Monty Python's Holy Grail or Spamalot, then you know what to do...

                      ****** RUN AWAY ******

This project is partially complete and requires debugging. Without deep 
knowledge
of FreeBSD initialization and internals, network programming, Python, 
and RTEMS,
this is a project you want to avoid. It is a good one but unless you 
have the magic set
of skills, it is also likely you will not succeed. And we don't want that.
> Also please explain the procedure to obtain committer access as 
> written here : http://rtems.org/wiki/index.php/Git_Committers
In general, very few people get commit privileges. Those that do have long
term associations with the project and have worked on multiple areas.

We prefer to have patches reviewed and a small number of folks who
do actually commits.

> Thanks for your support in advance.
>
> Regards
> Vipul Nayyar
> Computer Engineering
> Jamia Millia Islamia
> New Delhi
>
>
>
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130414/640a3ffa/attachment.html>