Date: Fri, 12 Sep 1997 13:22:42 +1000 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: gurney_j@resnet.uoregon.edu, mike@smith.net.au, freebsd-hackers@FreeBSD.ORG Subject: Re: PnP support Message-ID: <199709120322.NAA00969@word.smith.net.au> In-Reply-To: Your message of "Thu, 11 Sep 1997 13:33:33 %2B0200." <199709111133.NAA00141@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. Ask Jason just how kick-ass the extent manager is. It's *fast*, which isn't an issue from our POV really, but it also *works*, which is the whole point behind using it rather than reinventing our own wheel. > > > 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 :) True. > 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. Names are very opaque 8) > 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. *bleagh* mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709120322.NAA00969>