* John Levon <john.levon at Sun.COM> [2006-07-11 17:15]: > On Tue, Jul 11, 2006 at 11:28:18AM -0700, Stephen Hahn wrote: > > > We'll figure out how to make extended profiles take this (new) > > requirement into consideration. I am unconvinced by an argument based > > on a kernel debugger, rather than a larger set of applications; > > But this is precisely the sort of program that /has/ to care about the > platform. These "larger set of applications" will typically have no need > whatsoever to divine the platform - they care about `uname -p`. Thus the > reporting of the different platform should not affect those applications at > all. A kernel debugger (or, rather, a project that has the ability to modify one) can be the beneficiary of a new interface that can give more details about the loss of capabilities due to virtualization.
As a more concrete examples, how does this choice help a developer using $PLATFORM in a linker runpath (uname -i)? Or an adminstrator who has used $CPU in an automount map entry (uname -m)? > > moreover, I find it inconsistent that the zones' virtualization and > > the Xen virtualization would have different outcomes with respect to > > this informational interface. > > I think it's fairly clear that zones do not introduce anything even close to a > new hardware platform. I'm confused how this argument works for one form of software virtualization and against another. Xen has chosen to introduce a hardware platform, when one could as easily selected it to be an i86pc platform with distinct capabilities. > > Perhaps a pointer to some documented argument would convince me. > > I expect our PSARC case(s) will cover this in detail. In the meantime we'll > keep with the method-based approach we have now, and worry about the platform > issue if and when it arises, I suppose. ARC early, ARC often. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
