* Ingo Molnar (mingo@xxxxxxx) wrote: > with the big freaking difference that the 5 parallel implementations of > inode->i_op are: > > _internal to Linux_ Granted. Until it's modprobe xen.ko, vmware.ko, viridian.ko...that's not going to go away, even with the VMI. > Doh. There's only a data ABI underneath them. Perhaps from the syscall perspective. But there's also things like internal interactions with the page cache, VMA and pt updates, etc which are much more functional/behavioural than purely moving data. And when we're talking about page tables or simlar for hv, I think the data vs. functional is an oversimplification. > every time someone tried to impose a functional/behavioral ABI on core > bits of Linux we said: 'no way dude!'. Remember STREAMS? Remember the > module KABI? Remember ACPI? [doh, i guess we messed up on the latter > one. We regret that day ever since.] Heheh, OK, now I know I'm lost when we've both used ACPI as a negative example to argue our point. Honestly, all of the above suggest no VMI to me (in fact, I used those type of arguments against VMI about 1 year ago ;-). > (network file systems are a bit of an exception to the rule, but those > are pretty isolated themselves and in no way as wide and central as the > direction paravirt_ops appears to grow.) > > > > having data ABI coupling is one thing (filesystems, network formats, > > > etc.). But having a 5-way function ABI coupling between system > > > software running on the /same piece of hardware/, doing the same > > > thing in essence is just madness in my book. > > > > This is where I'm not understanding your argument. The hardware is > > somewhat irrelevant since the OS is running on a platform presented by > > the hypervisor. And the point is to allow multiple implementations of > > the OS opertations that interact with the platform. And in essence > > all network stacks and file systems are doing the same thing with the > > same hardware. [...] > > again, those are /DATA/ ABIs. Not function ABIs. Not behavioral ABIs. > The coupling is /FAR/ saner and far more plannable and far more > isolated. And even data ABIs are very non-trivial ... I agree that changing the interface to the low-level platform is tricky and less isolated. But how does the VMI protect you from those changes? It simply doesn't, the changes are still necessary. And the inflexibility means the tough corner cases swept under the VMI rug are more difficult to debug, get right, etc... thanks, -chris _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
