From owner-freebsd-hackers  Thu Sep 11 03:38:32 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA13158
          for hackers-outgoing; Thu, 11 Sep 1997 03:38:32 -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 DAA13144
          for <freebsd-hackers@FreeBSD.ORG>; Thu, 11 Sep 1997 03:38:26 -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 UAA00256;
	Thu, 11 Sep 1997 20:02:41 +1000 (EST)
Message-Id: <199709111002.UAA00256@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: mike@smith.net.au (Mike Smith), freebsd-hackers@FreeBSD.ORG
Subject: Re: PnP support 
In-reply-to: Your message of "Thu, 11 Sep 1997 11:13:45 +0200."
             <199709110913.LAA24117@labinfo.iet.unipi.it> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 Sep 1997 20:02:36 +1000
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > [... strategy ...]
> > The point I am making is that if you take this on, the parties 
> > responsible for these fields have already agreed on the course of 
> > action, and will be supporting you all the way.  You won't have to 
> > worry about jurisdiction at all.
> 
> ok. So a few more tech details. The resource management code should
> then keep a private list of used resources, with functions like
> haveseen_isa(), haveseen_pnp(), haveseen_pci() which check if any of
> the requested resource is busy and return a success only if all are
> free. Correspondingly there should be calls to make it possible to
> register/unregister resource usage. Possibly we should also have
> contigmalloc-like functions to return ranges of iospace etc within some
> desired constraint (useful to allocate PnP address ranges etc.).

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 :

 - the ISA startup code says "yup, this machine has an ISA bus", and 
   creates an extent called "isa_io" and another called "isa_mem"
 - the ESCD or ISA startup code would create an extent called "isa_irq"
   and another called "isa_drq" indicating the resources available
   to the ISA bus.

Traversal of these extents would then allow the PnP and vanilla-ISA 
probe/attach code to determine which regions were available for use and 
which had already been allocated.

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.

> Due to recent events :) , but also to the start of classes and to
> the need to keep developing the sound stuff, I don't have enough
> time to also rewrite this resource allocation stuff which is a
> necessary requirement to change the probe/attach sequence as
> discussed in [strategy] above, so is there any volunteer ?

I played a lot with the NetBSD extent allocator a while back.  Jason 
didn't entirely like what I was doing (and TBH some of my ideas were 
pretty warped), but I would be happy to start over and just add the 
important bits (extent names & owners, public extents).  I could 
probably have this ready in a few days.

mike