>>>>> "Ted" == Theodore Y Ts'o <[email protected]> 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