2006/525: New Boot Sparc

[Jan Setje-Eilers]

> Jan Setje-Eilers wrote:
> >> Peter Memishian has pointed out that the statement that
> >> /etc/path_to_inst is a "pure cache" is not correct.
> >> It is true that a functional instance file can be rebuilt
> >> but solaris does rely on the instance number ordering
> >> in the instance file not to change, otherwise devices
> >> could be renumbered.
> > 
> >  The only place these instance numbers are actually exposes is in
> > network drivers.   The fact that they are exposed there is a long
> > standing miss-architecture that will eventually (no immediate cut-
> > over due to compat. issues) be addressed by clearview.
> 
> The Clearview project doesn't completely remove that particular bit of 
> mis-architecture.  It just makes the impact less disastrous to 
> administrators.
> 
> The Clearview UV component legitimizes the administrative object which is 
> the datalink, and allows the administrator to give that object a 
> meaningful name (e.g., please give the name "isp3" to the datalink over 
> the bge0 device)  There is a device under that datalink, and that device 
> name is still at the mercy of path_to_inst.  If path_to_inst is munged in 
> such a way that what used to be "bge0" is now "bge2", then an 
> administrator will need to re-associate the "isp3" datalink with the 
> proper device by renaming links (i.e., manually using dladm(1M) 
> rename-link commands).
> 
> As a result I would say that path_to_inst is still a crucial piece of 
> system state during boot even after Clearview.
> 
> >  I had in fact prototyped a re-merge of an out of date path_to_inst
> > during boot, but was encouraged not to put that back with the archive
> > check changes since the only exposed issue this addresses is dr-ing in
> > more than one nic of the same flavor and then rebooting without
> > syncing the archive while caring which nic was which (not ipmp or an
> > aggr). While this situation is real, it is at least somewhat contrived
> > and the additional complexity of the re-merge didn't seem like
> > something we'd want to take give that another project was going to
> > eliminate the exposure entirely.
> 
> Would it always be safe to use the /etc/path_to_inst file in the / 
> filesystem as is being proposed for editable files and driver.conf files?
> 
> >  I'm still open to putting this back in, but we should feel like it's
> > something we'll want to keep around moving forward or just a temporary
> > bug fix.
> 
> If we can read the file that's in the filesystem, then I don't see the 
> need for the re-merge.

 If clearview continues to expose the internal instance number in the 
device name, then we should really re-merge path_to_inst on both 
sparc and x86.

-jan