Subject: nsswitch implementation questions...
To: None <current-users@NetBSD.ORG>
From: Luke Mewburn <lukem@telstra.com.au>
List: current-users
Date: 01/16/1996 15:22:01
Greetings all:
	I'm in the process of working my nsswitch implementation into
NetBSD-current, and I have an issue that I'd like to resolve before I
go any further.

In the present implementation, an external program parses
/etc/nsswitch.conf into /etc/nsswitch.db, so that programs have fast
lookup.

Some people aren't happy with this, so I'll outline the different
methods of interpreting the configuration file that I know of, and
the various pros and cons of each.

1. Parsing the file upon process invocation (e.g, Solaris <=2.4)
    Pros:	- easy to edit config file.
    Cons:	- need to restart daemons so that changes are picked up.
		- if a process starts parsing whilst an editor is writing
		  out the file, it could read a partial config file.

2. Parsing the file at each lookup if it has changed (e.g, ULTRIX /etc/svc.conf)
    Pros:	- changes are picked up immediately
    Cons:	- slowest method due to parsing overhead
		- potential to read partial config file (as above).

3. Talking via IPC to a daemon which restarts when a new parse is
   necessary (e.g, Solaris 2.5's nscd)
    Pros:	- faster than method 1
		- changes are picked up immediately? (not sure on this)
    Cons:	- need to have extra daemon running, with the various
		  overhead of ensuring that it's running, etc.
		- same parsing race condition as previous two methods

4. Reading a pre-parsed database on each lookup (e.g, my implementation)
    Pros:	- fastest lookup method
		- atomic update (via rename of temp file) of database
		  prevents race condition of other methods
		- all processes pick up changes to methods when
		  database is updated - no need to restart
    Cons:	- requires user to run 'ns_mkdb' when update is made.
		  (which does, however, provide the atomicity
		   described above)


I prefer method 4 (of course ;). I feel that because the nsswitch
will be used all the time, it needs to be fast. That is also why the
passwd database was converted to a 'db' database in 4.4BSD.

Can anyone outline any Real Good Reasons why method 4 is inferior to
method 1 or 2? Note that ULTRIX's svc.conf, which uses method 2, has a
much simpler syntax than nsswitch.conf, and is much easier (and
quicker) to parse.  I'm not even going to bother contemplate method 3;
I list it here for comparison only.

-- 
Luke Mewburn <luke.mewburn@itg.telstra.com.au>

                I'd rather be a UNIX wizard than a Web serf.