2006/525: New Boot Sparc

[Sebastien Roy]

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.

-Seb