From owner-freebsd-hackers  Thu Sep 11 20:54:42 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA27977
          for hackers-outgoing; Thu, 11 Sep 1997 20:54:42 -0700 (PDT)
Received: from word.smith.net.au (word.smith.net.au [202.0.75.3])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA27969
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 11 Sep 1997 20:54:37 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id NAA00969;
	Fri, 12 Sep 1997 13:22:42 +1000 (EST)
Message-Id: <199709120322.NAA00969@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: gurney_j@resnet.uoregon.edu, mike@smith.net.au,
        freebsd-hackers@FreeBSD.ORG
Subject: Re: PnP support 
In-reply-to: Your message of "Thu, 11 Sep 1997 13:33:33 +0200."
             <199709111133.NAA00141@labinfo.iet.unipi.it> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 12 Sep 1997 13:22:42 +1000
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > > This is why I exhorted you to look at the extent manager in NetBSD.  It
> > > allows you to define "extents" which are just arbitrary ranges of
> > > "something".  I would visualise this being used as follows :
> 
> ok, sounds like this is what we need. As a matter of fact it should be
> pretty simple code with some list manipulation stuff. Since we
> already have list management macros should not be a problem...
> unless of course we want to make this code memory-efficient, which
> we probably should since these maps take space forever whereas
> are used only when new devices are loaded/unloaded.

Ask Jason just how kick-ass the extent manager is.  It's *fast*, which 
isn't an issue from our POV really, but it also *works*, which is the 
whole point behind using it rather than reinventing our own wheel.

> > > I don't think that making these extents "private" would be at all
> > > helpful.  Having them public, and referenced by name, will make it
> > > easier to access them.
> 
> this is more related to religion :)

True.

> I feel much more comfortable with opaque objects since there is
> less risk that at some point someone exploits some features on the
> internals of the data structures thus effectively freezing them.

Names are very opaque 8)

> As an example of the opposite approach, Voxware exports the structure
> of DMA buffers to the application resulting in some restrictions
> on the acceptable blocksizes (powers of 2) etc.

*bleagh*

mike