Cc: Nakajima, Jun <jun.nakajima@...>, virtualization <virtualization@...>, Roland McGrath <roland@...>, Anthony Liguori <anthony@...>, Andrew Morton <akpm@...>, Linus Torvalds <torvalds@...>, <linux-kernel@...>, Jan Beulich <jbeulich@...>
the 'hardware is changing fast so we cannot do a sane API' argument
sounds good at first but in this context it is still fundamentally
wrong. Hardware has changed /dramatically/ since we started Linux, still
we didnt have to do dramatic changes to the system call API/ABI. Why?
Because hardware too is fundamentally controlled by the rules of this
world. So if you know the laws of physics, math and computer science,
you /CAN/ do a sane API that lives for quite some time. We had these
kinds of discussions when Linux was just a few years old - many people
were worried about 'the hardware changes too fast' - but if the
fundamentals are strong, it _doesnt really matter_, as long as our
interfaces are sane and we quickly adopt our internals.
On the other hand, Linux's internal details, semantics, approaches are a
lot more ad-hoc and alot more affected by changes in the hardware
environment - that's why i'd not like to see some external ABI
constraint limit aspects of those internals.
For example, VMI_CALL_SetAlarm takes a 'cycles' argument. Cycles is a
quite bad unit for an API, it should be absolute time, nanosec or
picosec based instead. We could easily see CPUs that have /no concept of
cycles/, at all! Even today's CPUs have hardly any fix concept of
cycles, due to cpufreq. It's as if 15 years ago we had based sys_mmap()
around the concept of '16-bit segments'. We could certainly make it work
on current hardware but it would look pretty awkward today.
in fact hardware changes alot more by just going from one Linux arch to
another - still the system call API is essentially the same. (with
small, non-fundamental variations)
furthermore, most of the details in VMI or in Xen's lowlevel APIs (where
most of the overlap is currently - VMI doesnt have all that many
highlevel APIs) are cast into stone. The i386 arch is not going to
change, ever. Most details of the x86_64 arch is not going to change,
ever. It's unclear whether there will ever be the need for any x86_128
arch (for humans). So it should be quite possible to come up with
something sane for these lowlevel details, and cast it into stone, for
everyone. Just like the chip makers cast it into silicon.
the more nontrivial (and thus more harmful, because more
design-limiting) bits are the highlevel APIs.
yeah, it's a nontrivial job - like writing a sane OS. But it's doable
and we are in fact out here trying to do exactly that, right? ;-)
Ingo
-
