On Mon, Mar 20, 2006 at 07:59:22AM +0000, Darren Reed wrote:
> On Mon, Mar 20, 2006 at 10:42:35AM +1100, Luke Mewburn wrote:
> > On Sun, Mar 19, 2006 at 08:41:14PM +0000, Darren Reed wrote:
> >   | 
> >   | In a discussion about how NetBSD opens and closes nls files way too
> >   | often, it was brought up that there are similar problems with the
> >   | name-number files like /etc/services and /etc/protocols.
> >   | 
> >   | So the problem is, what to do about it?  How can they be made quicker?
> > 
> > Have you profiled that these are a problem?
> 
> No, this is word of mouth from someone else.

I still fail to see what the big problem is even if many of these
perform sub-optimally.  They really should be relatively low use.
Why invent a very complicated system when it isn't really necessary?

Yes, it maybe cool to mmap files and all that but there are probably
many unforeseen consequences.  Seems like effort could be better
spent elsewhere.  I think it took SGI a while to get UNS, nsd(1M),
right.  There may still be problems with it as I don't really follow
IRIX that closely any longer.

From profiling I've done the biggest time sink in these routines
is the multiple passes through the strings when converting to the
*ent form.

> 
> > For /etc/passwd, getpwent(3) (et al) already use a db(3) database.
> > 
> > There's no reason we can't consider /etc/services.db (etc)
> > and implement an nsswitch "db" database lookup for these.
> > We have db(1) to easily create db(3) files.
> 
> For /etc/passwd, we have vipw.  For the other files, we do not,
> however, there's no reason we couldn't take the interaction with
> db (calling pwd_mkdb) out of vipw.
> 
> However, I'm not certain that a db(3) file will make the enumeration
> methods any quicker, vs just lookup a single entry by name/number.

Probably not the enumeration methods, but there are probably very
few things that truly need to enumerate through any of these
"databases".

Seems like BIND, the full blown distribution as used by BSD/OS,
might support db(3) files too.

> 
> I think I'd like to try the shared memory idea just to see if we can
> find a way to use this feature within the standard install base of
> NetBSD.  I just worry about the security concerns.
> 
> Using another db file seems easy but...it still has disk access
> latency (if we're really concerned about making things quick.)
> 
> Darren

Brian