Date: Thu, 11 Sep 1997 05:04:07 -0700 From: John-Mark Gurney <gurney_j@efn.org> To: Mike Smith <mike@smith.net.au> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <19970911050407.06011@hydrogen.nike.efn.org> In-Reply-To: <199709111002.UAA00256@word.smith.net.au>; from Mike Smith on Thu, Sep 11, 1997 at 08:02:36PM %2B1000 References: <199709110913.LAA24117@labinfo.iet.unipi.it> <199709111002.UAA00256@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970911050407.06011>