John Levon wrote: > On Mon, Apr 06, 2009 at 02:37:40PM -0400, Dave Miner wrote: > >> The goal there was to not be ISA-specific and use the standard names, >> but the change was clearly incomplete in terms of not re-locating to >> standard paths, which I had suggested in one of the conversations before it. > > The standard paths are most definitely ISA-specific, making the reason > for this change self-contradictory. >
The file names previously were also ISA-specific... >> That change had been in for two months before the issue was raised at >> the code freeze deadline, due to obvious lack of communication and test >> coverage that we've already discussed. This thread is part of ensuring >> we don't do that again. > > I certainly appreciate the heads-up. Perhaps some poor decisions were > made initially, that would have been different if there was awareness at > the time of the implicit interface contract on these paths. > Awareness is the key. Creating implicit contracts without notification is of course nothing but trouble, especially on products that are under such rapid evolution and are not operating with expectations of such dependencies. >> Were we following normal processes of ARCing before shipping products, I >> wouldn't expect /boot and /boot/amd64 to fly, given we already have >> established namespace in /platform for the exact purpose (somewhat >> ironically specified by direct boot). > > On the contrary, /boot/amd64 already exists and is essentially a stable > path - has been for a long time. There's no invention here. > Well, I had forgotten about it existing in dom0's. But it is at present an entirely xVM usage, so you'll have to excuse me there. >> None of this is hard. I simply am not that motivated by compatibility >> with 2008.11 on the expectation that most users of it would seem highly >> motivated to update. > > Apart from the embarrassment of not being to install our own software, > there is also Linux dom0. > >> The time to clean up inconsistent turds is now, before we are stuck >> with them for many years as the support horizons expand. > > I'm sorry but I just don't accept that this makes it OK to break things > without a really good reason. "Cleanup" is not it. If there's some nasty > details in place for the current paths, I can hear that argument, but > from the sounds of it this doesn't really exist. > So, I'm tired of the back and forth here. I'll propose this compromise: 1. I will restore the live CD to use the original /boot/x86.microroot path for 2009.06. 2. xVM will modify the fix from 6816065 to search /platform/i86pc/boot_archive, either in the 111a respin or in the next ON build possible, as well as the next scheduled Linux delivery, allowing us to migrate to the standard paths sometime in 2010, hopefully. 3. xVM engineering document any other existing dependencies on the live CD structure; something like what's in progress for AI will be acceptable. 4. Install QE and xVM QE devise a plan for regular regression testing of PV OpenSolaris live CD installs Anything else this should cover? Agreeable? Dave
