Stephen Hahn wrote:
> For one or more reasons, we have preserved a non-foliated space on x86
> platforms. I am trying to rediscover those reasons, because I believe
> that foliation in uname(2) has costs to a larger group of developers
> and administrators than the alternative choices. That is, our failure
> to be precise in the past may place requirements, if not constraints,
> on changes that might make one or more of these interfaces mutable.
I think that most of the things that are traditionally part of the
"platform" (like which kind of interrupt controller or what functions
the BIOS is expected to provide) don't actually vary much between an old
80386 PC and a modern Opteron server. Or at least the changes have taken
place in such small steps that it never made sense to declare a new
platform and compile/package different variations of some kernel modules
for each.
> I would argue that a precise "am I running in a virtualized
> environment" interface would be valuable to a large class of userland
> programs (say those desiring some not-too-exotic form of raw device
> access, like libusb consumers); having to know all the virtualized
> platforms or checking my zone name seems like a roundabout way of
> doing so. Perhaps I just like accurate error messages.
Maybe, but it should not be tied to the platform, which describes the
kernel's view of the machine. If the kernel is running on VMware,
the virtual machine is i86pc. If it's running on Xen with
paravirtualization it's i86xen, but when Xen provides hardware
virtualization we might be back at i86pc again. I think what you're
describing is more along the lines of assigning virtual resources to
physical ones so that an application can be told that on the present
machine, such-and-such resources can be found by such-and-such names.
There might be other reasons to change those mappings besides the fact
that some kind of virtualization is in use below the kernel.
> The scenario that led us here is that Xen images can be booted into
> either form, and that such a scenario is a possibility in certain
> deployments. Since we didn't change uname(2) on x86-derived systems
> for new ISAs (c.f. isalist, a new and precise interface) nor for
> multi-processors, I am still trying to figure why it's correct now. I
> suppose I would argue that, if we must foliate, we should go back and
> make sure that we've foliated correctly at other potential critical
> points.
I think there are a lot of little platform variations that exist on
various hardware systems that we support that would justify new
platform labels if they were correlated in meaningful bundles. But
since they are independent variables they aren't worth interpreting
as different platforms. For example, until recently, an i8042
keyboard controller was a required component for the i86pc platform,
but then the Intel MAC came along; we could create an i86mac
platform that is like i86pc except for the lack of this chip, but
for such an insignificant difference it's not worth it.
-=] Mike [=-
