Forseen performance problems with libchip (and other BIG PBS)

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

I have been looking a little bit to the libchip things and
I must say I'm totally disappointed by the "generic"
API definition.

in  serial.h we find :
		---------------------
typedef unsigned8 (*getRegister_f)(unsigned32 port, unsigned8 register);
typedef void      (*setRegister_f)(
                            unsigned32 port, unsigned8 reg, unsigned8 value);
typedef unsigned8 (*getData_f)(unsigned32 port);
typedef void      (*setData_f)(unsigned32 port, unsigned8 value);
		--------------------
			  
then latter in ns16559.c we see that each register is accessed
via call to the functions ptr.

I would like to recall that on PPC, motorola the function
getRegister_f can be implemented by a single movl instruction
and that using this API will imply to have for each interrupt
several additionnal indirect function calls compared to normal 
code execution.

On modern precessor architecture a function call costs much
more than the number of processor cycles it requires to perform 
it as it also implies :

     - two flushs of the instructon pipleine, and a two reload
     whih is extermely costly especially for one instruction 
     functions.
     - more cache misses, more memory accesses,

I would really like someone with the relevant hardware equipement
to benchmark a driver using this API and a normal driver. I would
not be surprised to get 40% performance degradation...

Other problems :

      1) "getRegister_f" should be "getRegister_p" as the mapping of
      PCI IO space and PCI ISA IO space is board dependent for example
      on PPC (you can have a look at the definition of inb in the linux
      source tree to be convinced...),
      
      2) The code that needs to be executed to handle an interrupt
      is BSP specific as the code that needs to be performed
      to acknoledge the interrupt is usually dependent on the
      interrupt mangement architecture (access to 8259 PIC to
      reenable the interrupt needed if SET_VECTOR is called).
      The actual code will never work on pc386 due to a more
      powerfull interrupt API for example...

So to summarize : 

   1) THE IDEA BEHIND LIBCHIP IS GOOD,
   2) WHAT IS CURRENTLY DONE IS REALLY BAD AS FAR AS I HAVE 
   ANY LEGITIMITY TO SAY THIS,
   3) We should start a more interactive spec of libchip API,

Missing API I can already see :

	typedef unsigned8 (*getRegisterSet_f)(...); to fectch 
	several contiguous registers

	typedef unsifgned (*getDataArea) (...)

In particular for PCI devices with on board memory,
accessing the data byte per byte is crasy...


-- 
   __                 
  /  `                   	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