Date: Tue, 22 Jul 1997 11:17:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, se@FreeBSD.ORG, Shimon@i-connect.net, freebsd-hackers@FreeBSD.ORG Subject: Re: pcireg.h lost children... ? Message-ID: <199707221817.LAA13674@phaeton.artisoft.com> In-Reply-To: <199707220226.LAA26105@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 22, 97 11:56:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. You are confusing my recognition of a "better than BSD decision" with your assumption that "because it's better than BSD, it's the best possible decision". This is hogwash; I am merely choosing the lesser of two evils any time I point at Microsoft as a model. > > 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. Right. "Nope". Because this is hardly what I was suggesting. I can access a locally stored dbm LDAP database using dbm. I don't have to use a network connection. This type of information, like the credentials necessary to get to the point where the network is up and credentials can be remotely obtained, *must*, by definition, be locally stored. Just so that you're aware, this problem was solved before outside the BSD camp at Novell, when providing NDS-based logons to UnixWare; UnixWare had to be brought up to the point where the net was up before the NDS calls could hope to go remote. This is not a new idea; it's an old idea which has been proven to be workable in a real-world situation. > 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. Yes; this is probably where it should live. It doesn't really matter, though, so long as it's on the root FS somewhere, since it will be accessed via kernel level file I/O. If it wasn't clear before, I'm not really for an SVR4-style BFS. > 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? If you are an MSDN level II developer (or better), there's some sane stuff that was published as part of the DDK DOCS directory that deals with it. My personal preference would be for NDIS 3.x, initially, and an only slightly more recent version for the power management features (specifically, how to make a stack come back up after a power down event). There's *some* stuff on the USU (*.usu.edu) FTP servers, where they keep all the NetWare stuff. Alternately, there is a driver developement kit you can get from Microsoft; they sendit to all the board vendors who want it. Really, the only reason for supporting it is to support new hardware for which we don't want to write drivers. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707221817.LAA13674>