Hi, Stephen,

Begging pardon, but doesn't every layer you shove in there as an abstraction
cost performance?  We already endure that price for our cross-platform
portability.

It's an admirable goal, to be sure, but I think we've already hit the
point of diminishing returns, unless we can somehow SERIOUSLY optimize the
pointer-to-function down to an actual function during the compile stage.

Or maybe I'm just totally losing it.  I just see our response times and
performance on the bottom rung or two by comparison to everything else
which runs on various architectures.

If I'm really off base, I'm sure someone will tell me.

				--*greywolf;

On Thu, 12 Apr 2001, Stephen Welker wrote:

# Date: Thu, 12 Apr 2001 12:46:59 +1000
# From: Stephen Welker <stephen.welker@nemostar.com.au>
# To: tech-kern@netbsd.org
# Subject: Uniform Driver Interface proposal
#
# Recently I have come across a concept that may be usefull for NetBSD. I
# wish to make people aware of this concept so that it may be discussed in
# the context of (1) NetBSD, (2) the ever increasing demand on new drivers,
# (3) cross platform development, (4) a common/published standard for driver
# writers, etc.
#
# This new concept is the "Uniform Driver Interface".
#
# A brief description...
#
# UDI, the Uniform Driver Interface, is a well-documented interface between a
# driver module and the executing OS. It provides source portability across
# OSes and binary portability within a processor ABI. It also provides modern
# driver features like instance independence, high scalability, and physical
# location transparency. The Reference Source provides an initial
# implementation of UDI for Linux, SCO UnixWare, SCO OpenServer, and other
# OSes.
#
# Another brief description...
#
# The UDI environment is a relatively autonomous, low-level I/O subsystem. It
# completely surrounds conforming device driver modules, providing them with
# a consistent interface to and from the host operating system and among
# cooperating drivers. Great care has been taken to isolate drivers from the
# "impedance matching" required for an I/O card to perform well on a given OS
# or platform. The driver is always invoked by procedure calls and interacts
# with the embedding OS and hardware via environment calls, providing the
# driver with full isolation from the details of its environment while
# retaining sufficient flexibility and performance in the OS.
#
# URLS...
#
# http://projectudi.sourceforge.net/
# http://www.projectudi.org/f-home.html
#
# Licensing, I believe, is the standard BSD License.
#
# Please note that I am not an expert in such matters, I am only submitting
# it to this forum for discussion so that if there are any benefits it may be
# integrated (optionally) into NetBSD.
#
# Please direct all public comments to the list and not to me - I am a
# subscriber to the list.
#
# --
# regards
# Stephen Welker
# Nemostar Pty Ltd
# http://www.nemostar.com.au/
#


				--*greywolf;
--
*BSD: If you look through Windows