Date: Fri, 12 Sep 1997 13:06:49 +1000 From: Mike Smith <mike@smith.net.au> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: Mike Smith <mike@smith.net.au>, Luigi Rizzo <luigi@labinfo.iet.unipi.it>, freebsd-hackers@freebsd.org Subject: Re: PnP support Message-ID: <199709120306.NAA00861@word.smith.net.au> In-Reply-To: Your message of "Thu, 11 Sep 1997 04:09:49 MST." <199709111109.EAA19340@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
(Man, and I thought today was going to be quiet. 8) > On Thu, 11 Sep 1997 20:02:36 +1000 > Mike Smith <mike@smith.net.au> 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. Fair enough; if you only have one "I/O space", you only want one map. > > - 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 was shooting for commonality of interface, ie. the extent manager can handle single-unit extents, so why write more code to handle a specific case? > > 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. On the contrary, names scale perfectly well. They're entirely opaque too. A probe/attach routine is handed a set of names which match the spaces it is working with, and it simply hands them off to the extent manager when it wants to allocate in those spaces. Calling them "names" may have been misleading; the intention was to imply an arbitrary and opaque token constructed in such a fashion that the space may be enumerated or queried by a caller with no connection to the creator or user(s) of the extent. > 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. This is kinda obvious, really. I can't imagine how you could have got it *wrong* (and it would appear that you didn't), if you thought about it for just a brief moment. > 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. I'd have to reevaluate a lot of it based on this thread; I'll try to do this though. > For example, I don't think you ever mentioned the idea of a "public extent". > (And, really, what does that _mean_?) Last time I looked at the extent manager, there was no facility for tracking created extents; a caller created an extent, and was given back a handle for it. A third party could only work with that extent if the creator had passed it a copy of the handle, or advertised it in some fashion. The concept behind "public" extents was simply that extents should be (optionally) registered by name when they were created, so that they could later be referenced by name as well as by handle. In addition, I was interested in adding some more accounting information to the manager, in order to track the "owner" and "purpose" of an extent. Your beef on these was the cost of moving the fields around; I can see that making them optional would be a win, but such a centralised avertising facility would forestall the abuse of these handles I can forsee. The other major bone of contention was the concept of shareable ranges; I wanted to see if we could use these for managing things like port range ACLs. Your objections and the extra complexity involved prettymuch killed that idea though. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120306.NAA00861>