> 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
