[GSOC] : Patches for merging different syslog.h

[Rempel, Cynthia]

________________________________________
From: Joel Sherrill [joel.sherrill at oarcorp.com]
Sent: Sunday, April 14, 2013 4:11 PM
To: Chris Johns
Cc: Rempel, Cynthia; rtems-devel at rtems.org
Subject: Re: [GSOC] : Patches for merging different syslog.h

On 4/14/2013 5:46 PM, Chris Johns wrote:
> Joel Sherrill wrote:
>> On 4/14/2013 11:50 AM, Rempel, Cynthia wrote:
>>> Wow, there are a lot of header files... Looks like we might be
>>> identifying which headers to not install more than merging, in either
>>> case, verifying each change to the installed headers won't break
>>> something will probably not be possible over the summer, so one of the
>>> primary goals of this project would be to outline how to identify
>>> which installed headers should be private (and not install them
>>> instead of merging them), and then outline how to merge the headers
>>> together by name.
>> Good point. Not installing a conflicting .h file is even better. :)
>>
>> If you only need <uart.h> to build your BSP. Leave it in the source
>> tree. This IS TESTABLE because the scope of the change is limited.
> When I last looked there where about 5 uart.h files and all were
> different so you need to find them, match them to the specific source
> and rename.
>
>> I am assuming that for chip specific .h files, this is possible but for
>> bus oriented ones
>> which might be used to access cards/devices added by the user, this is
>> not possible.
>> For example, user applications might include device drivers for VMEBus,
>> CompactPCI,
>> PCI, and AMBA bus devices.
-- I just remembered the user's guide said RTEMS worked with drivers to form a platform for writing applications...
-- So, it may be reasonable for a user to assume standards-based API's ship with RTEMS were intended...
-- In which case the user may be surprised if the header is no longer available...
-- The simplest test we could have to test these optional, but standards-based headers, would be a duplicate of a very simple test, with an extra #include for the optional, but standards-based header...
-- The optional, but standards-based headers should be commented with what standard the header is based on, (name / number, and year / version of the standard)
-- FWIW, although such headers are not typically needed by most open-source software, other deeply embedded systems have public driver-level headers...

> I seem to remember there is also case problems. One or more headers have
> different cases for the same name. This also needs to be fixed. The
> issues show up on file systems that are case insensitive.
Are you wanting all to lower case? Or just to compare "basename" in a case
independent manner?
-- We should verify there isn't a reason for different capitalization (such as compatibility with obscure software), if there isn't a reason we should write this up as a Google Code In project (correcting capitalization seems like a task geared towards high-school students...) 
> There are also a class of files with almost the same contents. These
> require more effort because you need to make sure you can merge them,
> rename them or what-ever.
And these are often deliberately duplicated since the RTEMS model is
to use the same file name supported by different targets and BSPs.
I hope we are proposing that  the files which do not fit "known patterns"
for source portability are the candidates.

In other words. We are not merging the contents of all bsp.h files. But
there shouldn't be twelve files installed as <bsp/uart.h> since that doesn't
fit any "portability pattern".
-- I agree.  I would propose the headers we have that are similar, but not standards-based, should be grouped together, and listed... then the next steps would be to identify standard interfaces that address this functionality, then converted to that format (we may want to use macros to maintain backwards compatibility), finally, a #include test written for each such header, and a generic Google Code in task written to document the updated interface.

That's why I said we had to know the rules for the duplicate file names.
bsp.h, bspopts.h, tm27.h, support for frameworks, are allowed.
Arbitrary reuse of an installed file name is not.
> Chris


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