Re: [patch] read[bwl] and ioremap problem

Re: [patch] read[bwl] and ioremap problem

[Theodore Y. Ts'o]

   Date:   Sat, 18 Dec 1999 15:50:19 -0800 (PST)
   From: Linus Torvalds <torvalds@transmeta.com>

   THAT case is certainly a rather strong argument for using something
   like "gsc_read[bwl]()" on HP-PA.

The other strong reason for doing gsc_read[bwl] on HP-PA is that some
PA-RISC boxes have both a GSC bus *and* a PCI bus, and you need to
access devices on both buses....

Something to consider is that for certain drivers, such as the serial
driver, I'm already having to do a serial_inp() which dispatches to the
proper {inb,readb,gsc_readb} already.  Yes I take a overhead/performance
hit for doing this, but it's the only clean way to support both ISA and
PCI serial boards in a single i386 box, or to support multiple buses in
the HP-PA scenario.

We've historically said that this kind of thing is horrible for
performance reasons, and the SCO and NetBSD approaches of doing
parameterized I/O has been derided for that reason.  However, it's
something that perhaps we should rethink; on modern CPU's, the extra
procedure activation/deactivation isn't *that* expensive, and it ends up
making the drivers much more portable and easier to support multiple
architectures.  The alternative is that each driver author ends up
writing their own I/O dispatch routines, such as what's currently in the
serial driver.  While this approach does have some advantages, in that
each driver author can decide whether or not he/she wishes to pay the
indirection overhead, it can mean code duplication and a delay before
certain devices get supported on non-mainline architectures.

Something to think about.

						- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch] read[bwl] and ioremap problem

[Jes Sorensen]

>>>>> "Ted" == Theodore Y Ts'o <tytso@mit.edu> writes:

Ted> We've historically said that this kind of thing is horrible for
Ted> performance reasons, and the SCO and NetBSD approaches of doing
Ted> parameterized I/O has been derided for that reason.  However,
Ted> it's something that perhaps we should rethink; on modern CPU's,
Ted> the extra procedure activation/deactivation isn't *that*
Ted> expensive, and it ends up making the drivers much more portable
Ted> and easier to support multiple architectures.  The alternative is
Ted> that each driver author ends up writing their own I/O dispatch
Ted> routines, such as what's currently in the serial driver.  While
Ted> this approach does have some advantages, in that each driver
Ted> author can decide whether or not he/she wishes to pay the
Ted> indirection overhead, it can mean code duplication and a delay
Ted> before certain devices get supported on non-mainline
Ted> architectures.

Oh it still is horrible ;-), and therefore it is something you don't
just want to implement in one big generic solution. You may want to
implement a generic interface that slow devices can use, but for some
high performance devices you really want the bigger freedom and the
option to control which parts are inlined and which are not. Ie. for a
Gigabit Ethernet or a high speed serial driver you may want to inline
parts of this in the fast path while using non-inlined versions for
the slow path bits of it (device initialization etc) to save space.

As a device driver author you may also want to use function pointers
rather than a list of if's for the non inlined case.

Jes

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/