From owner-freebsd-hackers Thu Sep 11 04:18:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA15132 for hackers-outgoing; Thu, 11 Sep 1997 04:18:14 -0700 (PDT) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA15116 for ; Thu, 11 Sep 1997 04:18:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.6/8.6.12) with SMTP id EAA19340; Thu, 11 Sep 1997 04:09:50 -0700 (PDT) Message-Id: <199709111109.EAA19340@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: localhost [127.0.0.1] didn't use HELO protocol To: Mike Smith Cc: Luigi Rizzo , freebsd-hackers@freebsd.org Subject: Re: PnP support Reply-To: Jason Thorpe From: Jason Thorpe Date: Thu, 11 Sep 1997 04:09:49 -0700 Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Sep 1997 20:02:36 +1000 Mike Smith wrote: > - the ISA startup code says "yup, this machine has an ISA bus", and > creates an extent called "isa_io" and another called "isa_mem" ...on the PC, it makes a bit more sense to just always manage the entire addressable range of i/o ports and memory-like space, rather than creating an ISA-specific map, etc. Think about e.g. PCI VGA cards, and their ISA compatibility range. Also, if you have an all-encompassing map like this, allocation of unused physical address space for e.g. memory-mapped EISA cards is much easier. You might want to take a look at NetBSD-current's i386 machdep.c - just look for the extent_* calls. > - 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. Erm ... an extent map is a bit overboard for this, I think - for drqs, a simple bitmap will suffice, and for irqs, and array of "share types", indexed by irq. > 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. Referenced by name can be problematic - On interesting machines, that simply doesn't scale. What you really want is to use opaque tags to reference "bus space". These tags are interpreted by machine-dependent code (which implements an MI API), and translate into the right thing. Last I heard, FreeBSD still wanted to run on the Alpha, and if that's the case, you're going to _have_ to think about this. For those wondering why it's problematic, you should take a look at an AlphaServer 8400 sometime - it can have multiple primary PCI busses, each with its own physical address space, and each of these primary PCI busses can host an EISA/ISA bus. NetBSD runs on this system, but it wouldn't have been possible if we hadn't paid careful attention to getting bus space accounting right. > 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. If you could write up a concise description of what the changes are (the last I got from you was a "well, this is basically what I did"), I'd be happy to reconsider my position on some of those things. For example, I don't think you ever mentioned the idea of a "public extent". (And, really, what does that _mean_?) Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: +1 408 866 1912 NAS: M/S 258-6 Work: +1 415 604 0935 Moffett Field, CA 94035 Pager: +1 415 428 6939