Date: Thu, 24 Jul 1997 14:16:34 -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: <199707242116.OAA18156@phaeton.artisoft.com> In-Reply-To: <199707230142.LAA04452@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 23, 97 11:12:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? Wrong. You only need to store local non-default configuration settings, and boot critical account data, etc.. All other user accounts can be remote. NIS operates this way; I don't understand why you would find the idea so alien. > > 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. *Non-default* configuration information. And we both agree that it needs to be somewhere; one somewhere is topologically equivalent to any other. > > 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? Ask. Don't make it obvious that you aren't a board vendor. They will assume you are by default, since that is the target audience. > ... 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. Yes; duplicate support routines is a hazard of running more than one brand of network card in the machine. 8-(. 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?199707242116.OAA18156>