David Kahn wrote: > > > Bart Smaalders wrote: >> Tarl Neustaedter wrote: >>> The knowledge of which driver to use within Solaris >>> isn't needed until after this stage - so I don't think it belongs in >>> the boot command in the first place. >> >> This is correct... and storing such driver info somewhere where a >> special program needs to update it is just plain broken. >> >> Solaris should be passed the _external_ info about its boot drive - >> and then should dynamically figure out how to talk to that external >> device. Any other approach will break when drivers change, >> paths to devices change, etc. > > That's what the FWARC case does today, so if you are agreeing > with that, then I agree with you. Is that what you mean, Bart? >
Yes.... I'm working on the new packaging system for Solaris next, and we don't use an "installer" or "upgrade" program; instead, changes are made to the delivered files as specified in the packages. There is no release-specific code that gets run to perform arbitrary fixups to config files, such as determining kernel-internal boot paths, etc. Today, w/ ZFS root (mandatory in Solaris next for a variety of reasons) this works well on both SPARC and x86 although USB connected storage devices still need some help. The first iscsi proposal required an installer program (running on the previous release being upgraded via zfs clone) to compute the new kernel's internal boot paths so that the new kernel could boot. Needless to say, this would create significant technical and management issues; since we manage to boot a ubiquitous CD image, dynamically discovering paths to that device after initial image load, I believe that we can and should do the same for iscsi boot devices. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
