* Chris Wright <chrisw@xxxxxxxxxxxx> wrote: > > 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. with the big freaking difference that the 5 parallel implementations of inode->i_op are: _internal to Linux_ Doh. There's only a data ABI underneath them. 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.] (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 ... Ingo _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
