* Chris Wright <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
