>I'm feeling dense - how does this win?

Assuming you mean the single "devsw" (instead of separate b/c devsw):
mainly, it cuts the number of "kernel to device" interfaces in half.
Since the devsw data structure itself is defined in the device driver
file, e.g.:

	/* in sd.c */
	struct devsw sdsw = {
		&sdcd,
		sdopen, sdclose, rawread, rawwrite, sdioctl, seltrue, nommap,
		sdstrategy, sddump, sdsize, 0,
		nostop
	};

all of the driver functions can be made static.

(Admittedly, one can do the same with two separate "sw" structures:
sd.c could define sdsw_blk and sdsw_chr, instead of a single unified
"sdsw".)

There is no #ifdef-infested conf.c to trip over -- BSD/OS has
"config" generate, in ioconf.c, a table of pointers:

	/* in sparc/conf/ioconf.c.sparc */

	%CONFIG
	...
	%DECLSW
	...
	struct devsw *devsw[] = {
		...
		%DEVSW(sd),		/* 17 = SCSI disk */
		...

The %DEVSW directive tells config to emit NULL if "sd" is not
selected (no "sd" devices), or "&sdsw" if "sd" is selected.

(Admittedly, the initialized devsw[] table only works for drivers
that are not demand-loaded.  One still needs some kind of table or
list, though, to map from Unix-style major device number to driver
entry points.  A table is a very convenient data structure, and
unless one has a fully-dynamic "/dev", the major numbers must be
fixed to prevent disasters.  Of course, one could again have two
separate devsw tables, for block vs char, but this makes twice as
much room for mistakes.)

Finally, if there is only one number per device, the opportunities
for getting the numbers backwards when making /dev entries (and
subsequently blowing away something important) are essentially gone.

Chris