Date: Tue, 22 Jul 1997 11:56:49 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, terry@lambert.org, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? Message-ID: <199707220226.LAA26105@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707212104.OAA11882@phaeton.artisoft.com> from Terry Lambert at "Jul 21, 97 02:04:10 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > Now, if we remove this information from the driver and put it > > somewhere in a Big Central Localtion, like, oh say W95 does (seeing as > > you respect their design decisions), the central localtion can be > > updated rapidly without having to rebuild and reinstall the driver. > > I don't exactly respect their design decisions; it's just that, > given a choice between some of the BSD design decisions and the > Win95 design decisions, I'd pick the Win95 where ever they've made > tradeoffs in favor of ease of use and BSD hasn't. "I don't respect their decisions, except where I respect them". Erk. > > Nifty, eh? > > Yes, if it's only a trade of location and not one of size, then > abstraction is the correct apporach, when possible. More to the point, localisation of this sort of data makes management of said data much easier. > I was actually looking at the draft proposal for the LDAP MIB for > POSIX systems, the other day. It seems to me that a locally > maintained LDAP breanch accessed through a local library that > could go remote if the information wasn't there, and wasn't able > to try to go remote until the network services were actually up, > is the correct future direction for UNIX password files, etc.. > > And probably this information, as well. Yeah. Insert a new network card. See a message saying "waiting for a network connection so I can get details on this new network card". Nope. My initial preference actually would be to load the entire table into memory during the boot process, pull out the values that match the installed hardware and ditch the remainder. This naturally wins if the file containing the table is somewhere tidy like in /boot or on the hypothetical boot filesystem. Speaking of network drivers; a while back you were blathering about how we should consider supporting 32-bit NDIS drivers via a module interface. Do you still think this? I spent some time reading what (little) Microsoft have made public about the new NDIS 5.x spec and TBH it looks like a monster. Is there an older, saner spec that's worth perusing anywhere? > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707220226.LAA26105>