csb337 compile problem

[Ralf Corsepius]

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.

Ralf