Forseen performance problems with libchip (and other BIG PBS)

[valette at crf.canon.fr (VALETTE Eric)]

>>>>> "Mark" == Mark Johannes <mark.johannes at oarcorp.com> writes:

Mark> We need to remeber that this first version of libchip is at best a
Mark> proof-of-concept to determine the fitness of the ideas.  This high-level
Mark> design is a broad interpretation of all the devices that exist within the
Mark> embedded domain. 

I have to disagree a bit here : the API for libchip has been designed to
support some very elementary chipset like RTC/serial lines chipset.
Todays, in the embedded PC/PowerPC/Sparc world, PCI is everywhere and more
and more board use this bus interface ( or compatible one CompactPCI,PMC, ...) 
or other VMEBUS,...

REAL Support for PCI bus is nearly inexistant in RTEMS because besides readding
the PCI configuration registers (which is easy), you must 
handle them. This includes :

       - Mapping on board memory or registers non cacheable,
       - Supporting several interrupt handler connected to the same IRQ
       source (due to PCI requirement for boards having a single interrupt source..),
       - allocating cache/Page alligned memory regions,
       - having ways in the driver to insert machine specific code
       to acknowledge an interrupt at external PIC level at the beginning
       of the interrupt routine,
       - Support for transfering contiguous block of data from PCI board, to 
       processor  memory (for cards without DMA) or the other way,
       - A way to collect reclaim IO regions so that when programming
       a PCI card in IO mode (which I would not recommand) will not conflict
       with other IO zone requested by other devices or legacy (PC like)
       IO zone,...
       - Eventually flushing cache after DMA transfer, 
       - ...


Marks> We all are aware that what is good for one family of
Mark> processors can be very wrong for another, case in point Eric's concerns.

No. This is not my only concern. My concern is that the API proposed
is :
   - far too simplistic,
   - has already problem with BSP support (like PC 386 interrupt handling
   enhaced API),
   - introduce performance problems,

Mark> I believe this will be an interesting, challenging, and enlightning task to
Mark> bear out these details to achieve a feasible BSP architecture that will not
Mark> only be performance oriented, but also modular enough to support
Mark> "cut-and-paste" BSP development.

Do not worry : I still support the idea behind libchip and will make my
best to enhance it. But I would rather go for a more sophisticated things
because the current one already does not fit my needs...

-- 
   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Canon CRF
(___, / (_(_(__         	Rue de la touche lambert
				35517 Cesson-Sevigne  Cedex
				FRANCE
Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr