From owner-freebsd-hackers Thu Sep 11 05:04:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA16999 for hackers-outgoing; Thu, 11 Sep 1997 05:04:30 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16994 for ; Thu, 11 Sep 1997 05:04:24 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id FAA25178; Thu, 11 Sep 1997 05:04:08 -0700 (PDT) Message-ID: <19970911050407.06011@hydrogen.nike.efn.org> Date: Thu, 11 Sep 1997 05:04:07 -0700 From: John-Mark Gurney To: Mike Smith Cc: Luigi Rizzo , freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support References: <199709110913.LAA24117@labinfo.iet.unipi.it> <199709111002.UAA00256@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199709111002.UAA00256@word.smith.net.au>; from Mike Smith on Thu, Sep 11, 1997 at 08:02:36PM +1000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith scribbled this message on Sep 11: > > > [... 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. hehe... I was just thinking about this.. and writing a spec that was very similar to this.. but I was also trying to extend the spec to support the removal of resources (i.e. pccard gets removed)... > 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. I agree... I assume your talking about id numbers?? > > 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. hmm... this sounds nice... I'm in the process of writing my spec, but would be interested in seeing what you have already... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD