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. > 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. > 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. > 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. regards john
