On Fri, Feb 07, 2003 at 06:21:08PM +0100, Hubert Feyrer wrote:
  | On Fri, 7 Feb 2003, Ben Harris wrote:
  | > While I think you're right that MAKEDEV could use some work, I'm
  | > not sure that extending mknod is the way to go. In particular,
  | > remember that in a diskless environment, MAKEDEV usually gets run
  | > on the NFS server, which may well not be running NetBSD, and even
  | > if it is running NetBSD is likely to be a different architecture
  | > and version from the system whose /dev is being populated. MAKEDEV
  | > isn't as portable as it could be, but making it even less portable
  | > would be a bad idea IMO.
  |
  | Seconded.
  | And there's also mtree...

For a "what if" exercise a while ago, I (ab)used the code I wrote for the
creation of distrib media to create "mtree specfiles" from the output of
MAKEDEV (c.f, distrib/common/Makefiles.makedev when MAKEDEVTARGETS != "").
Then, instead of running "MAKEDEV all" at boot to populate /dev, you
run mtree -f devices.spec.

IIRC, it worked fine, but then you required mtree.  That said, if you are
cross building from a server to a client, you will have $TOOLDIR/bin/nbmtree
on the server, and that should DTRT with device numbers on the target.

I decided to repeat the exercise.  On an empty mfs file system,
here's the results of "time /dev/MAKEDEV all" on a PIII-600 (with
the mfs cleaned before each run):
	0.671u 1.336s 0:07.90 25.3%     0+0k 30+3649io 1pf+0w
	0.819u 1.231s 0:07.89 25.8%     0+0k 0+3622io 0pf+0w
	0.766u 1.249s 0:07.82 25.5%     0+0k 0+3620io 0pf+0w

I then ran
	(
	    echo ". type=dir";
	    env MAKEDEVSCRIPT=/dev/MAKEDEV \
	    	sh /usr/src/distrib/common/MAKEDEV.wrapper all | \
	    	awk -f /usr/src/distrib/common/makedev2spec.awk | \
		sed -e 's,^\./dev,.,' | \
	    	sort
	) > /tmp/devices.spec
which took ~ 2.61 seconds.  This is effectively a "once off" as
you only need to recreate devices.spec if MAKEDEV changes.

I then ran "time mtree -f /tmp/devices.spec -ue", with the directory
cleaned between each run:
	0.121u 0.382s 0:00.55 90.9%     0+0k 0+3599io 0pf+0w
	0.138u 0.364s 0:00.55 89.0%     0+0k 0+3602io 0pf+0w
	0.159u 0.350s 0:00.56 89.2%     0+0k 0+3601io 0pf+0w

A fair bit quicker...


Luke.