Re: The end of embedded Linux?

From: Nicolas Pitre (nico@cam.org)
Date: Mon Oct 07 2002 - 11:05:16 EST


On Mon, 7 Oct 2002, Russell King wrote:

> On Mon, Oct 07, 2002 at 03:36:44AM -0700, David S. Miller wrote:
> > No one else can run these drivers so
> > how could I expect someone else to maintain them ?
> >
> > This is a common misconception.
>
> Double that. There are lots of drivers for embedded ARM stuff that
> should probably be in the tree, but because they typically add
> architecture specific crap to drivers to modify the IO support
> the weird and wonderful way the hardware designer has come up with
> to connect the device. Examples of this are cs89x0.c and smc9192.c.
>
> I've tried to coerce people in Alans suggested direction (hiding
> the architecture specific stuff behind inb and friends) but That
> Doesn't Work because embedded people will not do this.

And embedded people won't do that for many reasons:

1) It's unwise to bloat every use of inb() and friends through out the
   kernel just because a single driver needs a special fixup.

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.

3) Getting the best code efficiency out of inb() and friends is therefore
   premordial on those platforms which are sensitive to code performance to
   achieve maximum bandwidth and power efficiency. Remember that most of
   embedded platforms where the SMC91C96 is used to pick up that example
   aren't able to accomodate any form of DMA à la PCI most of the time.

So even with the current situation where inb() and friends are tweaked
directly in each individual drivers I often see over 50% CPU usage in kernel
space just by copying files over NFS. Going with Alan's suggestion as you
mentioned many times on linux-arm-kernel is just not acceptable.

There really should be a way to abstract things so the proper fixup is done
once at compilation time rather than across the board for every inb() access
at run time.

I'm sure those who take care of abstracting the code for SMP capabilities so
it nicely becomes a no op on UP at compilation time understand this issue
pretty well. This should be the same for IO macros with embedded systems.

Nicolas

-
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