* Ingo Molnar (mingo@xxxxxxx) wrote: > > * Chris Wright <chrisw@xxxxxxxxxxxx> wrote: > > > What are you driving at? You seem to be arguing that abstractions are > > bad unless done via ABI's. [...] > > i'm still arguing the same: that doing the same thing via overlapping, > conflicting, redundant ABIs is crazy and contrary to the basic interests > of Linux. It's like having 5 different, parallel variants of sys_open(), > interfaced via a convoluted open_ops. I would've said 5 parallel implementations of inode->i_op simply given the nature of the operations, which is entirely sane. > 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. Here's the reality. None of these hypervisors will be ABI compliant in the way syscalls are (namely trap insn and hypercall number). So there's a bunch of glue wherever you design the system. Your arguement is that in some (arguably random) instances it makes sense to push the glue into the ROM. This idea that lguest and KVM come from the same source tree is irrelevant when the issues you site are about support matrices (which means that guest and host may not have come from the same source afterall). I still don't understand your issue. thanks, -chris _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
