From owner-freebsd-hackers Thu Sep 11 05:56:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA19572 for hackers-outgoing; Thu, 11 Sep 1997 05:56:06 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA19531 for ; Thu, 11 Sep 1997 05:56:00 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA00141; Thu, 11 Sep 1997 13:33:33 +0200 From: Luigi Rizzo Message-Id: <199709111133.NAA00141@labinfo.iet.unipi.it> Subject: Re: PnP support To: gurney_j@resnet.uoregon.edu Date: Thu, 11 Sep 1997 13:33:33 +0200 (MET DST) Cc: mike@smith.net.au, freebsd-hackers@FreeBSD.ORG In-Reply-To: <19970911050407.06011@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 11, 97 05:03:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > 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 : ok, sounds like this is what we need. As a matter of fact it should be pretty simple code with some list manipulation stuff. Since we already have list management macros should not be a problem... unless of course we want to make this code memory-efficient, which we probably should since these maps take space forever whereas are used only when new devices are loaded/unloaded. > > 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. this is more related to religion :) I feel much more comfortable with opaque objects since there is less risk that at some point someone exploits some features on the internals of the data structures thus effectively freezing them. As an example (I am sure you can have many yourselves) I did use a semi-opaque description of dma buffers in the sound code and I am *very* glad I did that since this has allowed me to change radically the dma code twice with zero impact on the rest of the sound code. As an example of the opposite approach, Voxware exports the structure of DMA buffers to the application resulting in some restrictions on the acceptable blocksizes (powers of 2) etc. I think that if haveseen_isa() had used private resource maps instead of relying on the availability of global variables we would not be discussing this now. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________