Nicolas Pitre wrote:
>
> On Mon, 7 Oct 2002, Mark Mielke wrote:
>
> > On Mon, Oct 07, 2002 at 09:02:33AM -0700, David S. Miller wrote:
> > > From: Nicolas Pitre <nico@cam.org>
> > > Date: Mon, 7 Oct 2002 12:05:16 -0400 (EDT)
> > > 2) Not inlining inb() and friend reduce the bloat but then you further
> > > impact performances on CPUs which are generally many order of
> > > magnitude slower than current desktop machines.
> > > I don't buy this one. You are saying that the overhead of a procedure
> > > call is larger than the overhead of going out over the I/O bus to
> > > touch a device?
> >
> > I think the key phrase is 'further impact'.
> >
> > If anything, the procedure call increases latency.
> >
> > Although... I don't see why CONFIG_TINY wouldn't be able to decide whether
> > inb() should be inlined or not...
>
> Please don't mix up the issues.
>
> The problems with inb() and friends as it stands in the embedded world right
> now as to do with code cleanness not kernel image bloat. Nothing to be
> solved with CONFIG_TINY. Please let's keep those issues separate.
>
> Here's the IO macro issue: On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc. All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
>
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with. Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.
>
> We therefore end up with something that looks like this in each drivers for
> which a fixup is needed:
>
> #ifdef CONFIG_ASSABET_NEPONSET
>
> /*
> * These functions allow us to handle IO addressing as we wish - this
> * ethernet controller can be connected to a variety of busses. Some
> * busses do not support 16 bit or 32 bit transfers. --rmk
> */
> static inline u8 smc_inb(u_int base, u_int reg)
> {
> u_int port = base + reg * 4;
>
> return readb(port);
> }
>
> static inline u16 smc_inw(u_int base, u_int reg)
> {
> u_int port = base + reg * 4;
>
> return readb(port) | readb(port + 4) << 8;
> }
>
> static inline void smc_outb(u8 val, u_int base, u_int reg)
> {
> u_int port = base + reg * 4;
>
> writeb(val, port);
> }
>
> static inline void smc_outw(u16 val, u_int base, u_int reg)
> {
> u_int port = base + reg * 4;
>
> writeb(val, port);
> writeb(val >> 8, port + 4);
> }
>
> #endif
>
> As you can see such code duplicated multiple times for all bus arrangements
> in existence out there is just not pretty and was refused by Alan. We lack
> a global lightweight IO abstraction to nicely override the default IO macros
> for individual drivers at compile time to fix that problem optimally and
> keep the driver proper clean.
Uh, what about stuff like this (from tulip.h):
#ifndef USE_IO_OPS
#undef inb
#undef inw
#undef inl
#undef outb
#undef outw
#undef outl
#define inb(addr) readb((void*)(addr))
#define inw(addr) readw((void*)(addr))
#define inl(addr) readl((void*)(addr))
#define outb(val,addr) writeb((val), (void*)(addr))
#define outw(val,addr) writew((val), (void*)(addr))
#define outl(val,addr) writel((val), (void*)(addr))
#endif /* !USE_IO_OPS */
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:59 EST