As soon as you try to manage multiple classes of hardware with one
loadset, you run into a problem with the way that Solaris handles
devices and drivers.

One way to handle this would be to make all of these negative, and let
devfsadm handle everything.  The way we manage this is to create an
"overload" for each class of hardware, which consists of all devices,
device links, and other hardware-specific files (e.g. /etc/path-to_inst).

These get managed in the class overload:
d /dev			(mostly symlinks to stuff in /devices)
d /devices		(where real device nodes exist)
f /etc/path_to_inst	(unique for each hardware class)

These get managed in the positive transcript:
f /etc/devlink.tab
f /etc/driver_aliases
f /etc/driver_classes
f /etc/minor_perm
f /etc/name_to_major

Our command file then looks something like this:

p sol8-positive.T
p sol8-negative.T
p hardware-class-overload.T

The positive transcript does not contain any devices or links.  Our
procedure for adding support for a new class of hardware is:

1) boot from cd, load machine
2) devfsadm -C -r /mnt -p /mnt/etc/path_to_inst (build working file) 
3) make sure /etc/vfstab is correct!
4) rm /etc/path_to_inst.old
5) run fsdiff, you should have an overload for this class of hardware

If the new hardware required special drivers or kernel modules, we 
make sure to merge all of the changes (e.g. /etc/name_to_major) back
into the positive transcript.

**
Things to figure out
**

The /etc/path_to_inst sort order is not always consistent on all of our
hardware.  I can't figure out yet why this happens.  The file contents
are exactly the same, but the order is different.

Sometimes devfsadm will create symlinks to the disks with very odd
numbering schemes (e.g. /dev/dsk/c72t1d0s0).  I'm still trying to figure
out what things in /devices can be safely deleted prior to running
devfsadm.

**
Interesting stuff
**

When you boot off the Solaris 8 CD, /etc/path_to_inst only has 1 line:
#path_to_inst_bootstrap_1