[PATCH/RFC] Hookable IO operations

Arnd Bergmann arnd at arndb.de
Sat Nov 4 09:48:37 EST 2006


On Friday 03 November 2006 23:32, Benjamin Herrenschmidt wrote:

> > If you leave out the 'extern', it fits into a normal line ;-)
> 
> Did I change them from the initial definition ? Anyway, I dislike
> prototypes in headers without "extern".

I prefer writing down the extern as well, but the common style
seems to have moved away from it now.

> 
> > > +
> > > +extern void (*__memset_io)(volatile void __iomem *addr, int c,
> > > +			   unsigned long n);
> > > +extern void (*__memcpy_fromio)(void *dest, const volatile void __iomem *src,
> > > +			       unsigned long n);
> > > +extern void (*__memcpy_toio)(volatile void __iomem *dest, const void *src,
> > > +			     unsigned long n);
> > 
> > Why are these all separate symbols? Wouldn't it be clearer to group them
> > in ppc_md, or a similar structure of function pointers?
> 
> Because the IO ones are separate already and I want to keep things
> consistent with them.

Actually I meant all of the I/O pointers, not just these three. When
you were describing your idea to me, I was thinking of something like

struct ppc_io {
	void (*writeb)(u8 val);
	void (*writew)(u16 val);
	void (*writel)(u32 val);
	void (*writeq)(u64 val);
	...
	void (*memset_io)(volatile void __iomem *addr, int c,
				 unsigned long n);
	void (*__memcpy_fromio)(void *dest,
			const volatile void __iomem *src, unsigned long n);
	void (*__memcpy_toio)(volatile void __iomem *dest,
			const void *src, unsigned long n);
} *ppc_io;

Did you never consider this, or did you make your mind up in the
process?

Is your current code more efficient?

> > > -static u8 iSeries_Read_Byte(const volatile void __iomem *IoAddress)
> > > +static u8 iseries_readb(const volatile void __iomem *IoAddress)
> > 
> > Since you're converting iSeries_Read_Byte from SilLycAps, shouldn't
> > you change IoAddress to something more sensible at the same time?
> 
> No, I'm only changing the prototype & name to better match my hooks,
> further cleanups of the content of these functions is something I'll do
> in a separate patch.

ok, makes sense.

	Arnd <><



More information about the Linuxppc-dev mailing list