Date: Wed, 23 Jul 1997 11:12:39 +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: <199707230142.LAA04452@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707221817.LAA13674@phaeton.artisoft.com> from Terry Lambert at "Jul 22, 97 11:17:04 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > > 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". You are confusing "respect" and "worship". > > 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. ... and by extension about the only thing that's left worth having in the remote database is information for hardware that isn't involved in getting to that stage, ie. soundcards. Not what I'd describe as terribly helpful, no? > 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. Accessing user credentials is just ever so _slightly_ different to accessing configuration information for operation-critical hardware. > > 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. I am not, as I have repeatedly stated. At this point, I am not willing to - be listed or recognised by Microsoft as a supporter in any way shape or form. - haemorrhage money paying for documentation that is rarely going to be of use. > 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). My concern is whether NDIS 3.x drivers are likely to be available as a long-term future constant. > There's *some* stuff on the USU (*.usu.edu) FTP servers, where they > keep all the NetWare stuff. Ta. > Alternately, there is a driver developement kit you can get from > Microsoft; they sendit to all the board vendors who want it. As a non-board vendor, how does one qualify for this? > Really, the only reason for supporting it is to support new hardware > for which we don't want to write drivers. ... or can't. This is exactly the reason for doing it. In addition, the reading I've done does actually imply that the architecture is reasonably sane, even if it does offload too much work (IMHO) onto the card. > 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?199707230142.LAA04452>