> > > > A scenario for this problem is: In a shared SAN > environment, > > the same tape device needs to be named the same on > all the hosts > > so that the backup software can be configured > consistently > > across the enterprise. > > > > Current /dev/rmt name scheme can assign different > /dev/rmt# > > on different host even for the same tape drive. > > > > As long as the /dev/rmt# is the same for the same > tape drive, > > it is okay to be a symlink or anything else. > > Now that is a good example. Even here though I'm not > convinced that altering the semantics of the > /dev/rmt/# > system we have currently is the right approach; > allowing > user-defined device aliases on top of that might be > attractive.
It is also possible to collect the shared tape device names in a separate directory, like /dev/tape. > > > > > - automatic discovery of new device names, in > the > > > case of forgetting > > > > the special "-r" flag in the boot command > (ref. > > > CR 5050715). > > > > > > Isn't automated USB detection already integrated > even > > > in S10U1? > > > > The cold-plugged device scenario is what we are > trying to help. > > Imagine a non-hotpluggable device (say some scsi > disks) is > > plugged into the system while it is powered off, > the ctd names > > won't be created if the user forgot to boot the > system with > > the "-r" flag. > > Absolutely. The current behaviour is exactly what I > require. > The systems shouldn't create device nodes in these > cases without > my explicit involvement. How do you know that when > the system > didn't have the -r boot flag, that it wasn't > deliberate? Well, a Solaris guru may find it entertaining to play with the special "-r" boot flag :-). To a new Solaris user that comes from other OS, (s)he may find it bothersome not to find the device after a normal system reboot has performed. Then they will ask, "what is the problem with Solaris?" Lucy This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
