csb337 compile problem

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Wed, 2004-11-03 at 06:44, Lars Munch wrote:
> 
>>On Tue, Nov 02, 2004 at 03:58:28PM -0600, Joel Sherrill <joel at OARcorp.com> wrote:
>>
>>>Delete "#include <bsp.h>" in rtc/mc146818a.c.  It isn't supposed
>>>to need that file.
> 
> 
>>So I guess my quick fix to this problem (see previous post) was valid
>>enough?
> 
> 
> Well, you only have worked around one problem, which might be sufficient
> in your case, but there is more to it:
> 
> 
>>>From your previous mail:
> 
> 
> ../../../csb337/lib/include/libchip/serial.h:25: conflicting types for
> `getRegister_f'
> ../../../csb337/lib/include/libchip/rtc.h:22: previous declaration of
> `getRegister_f'
> 
> I.e. both headers declare "getRegister_f" and disagree about it.
> => We have an API problem here. Either both types should be made
> namespace safe (e.g. prefixed by an appropriate string
> "serial_getRegister_f"), or a general API should be implemented.
> 
> IMO, in this case only the first approach makes sense.
> 
> 
>>  I guess you also need to delete it in rtc/mc146818a_ioreg.c
>>then.
> 
> 
> Well, rtc/mc146818a_ioreg.c is subject to yet another problem.
> 
> It uses 2 functions, "input_byte" and "output_byte", which currently are
> not covered by any (internal or external) RTEMS API (i.e. they are not
> declared by any cpu/bsp-independent header)
> 
> ATM, these 2 functions are only provided for few BSPs:
> # find . -name '*.h' -exec grep -H inport_byte {} \;
> ./c/src/lib/libbsp/powerpc/motorola_powerpc/include/bsp.h:#define
> inport_byte(port,value) (value = inb(port))
> ./c/src/lib/libbsp/powerpc/ppcn_60x/console/vga_p.h:   
> inport_byte(0x3c5, val)
> ./c/src/lib/libbsp/powerpc/ppcn_60x/console/vga_p.h:           
> inport_byte(0x3da, ucDummy); \
> ./c/src/lib/libbsp/powerpc/ppcn_60x/include/bsp.h:#define
> inport_byte(port, val\./c/src/lib/libcpu/i386/cpu.h:#define
> i386_inport_byte( _port, _value ) \
> ./cpukit/score/cpu/i386/rtems/score/i386.h:#define inport_byte( _port,
> _value )  i386_inport_byte( _port, _value )
> 
> I.e. ATM rtc/mc146818a_ioreg.c violates RTEMS's APIs, and relies on BSPs
> providing these 2 functions (IMO, this file should have never been added
> to libchip :-) ). 
> 
> So, for the moment the only way to get this file functional for those
> BSPs actually providing the 2 functions is to "include <bsp.h>". For
> those BSPs not providing these 2 functions, you'll see a several
> compiler warning and get non-function objects.
> 
> 
>> Could yo please apply this to cvs?
> 
> I'll remove <bsp.h> from mc146818a.c, but not from mc146818a_ioreg.c. 
> 
> mc146818a_ioreg.c need a fundamental redesign, either of its API or the
> BSPs using it.

I thought about this issue while looking at the include issue.  I think
it would be best to move it to libbsp/shared and make it compiled only
by the pc386 and motorola_shared BSP (as part of TOD).

in/out byte are not going to be part of the general RTEMS API any time
soon.

I would ignore the ppcn_60x.  It is on my deprecation list for 4.7 
unless a volunteer shows up.

How does that sound?

> Ralf
> 
> 


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