> But I can leave that aside, since it's your code, even though I
> disagree with it's appropriateness. What I strongly object to is the
> bloat that is added to the kernel to support your model. If DIPC was
> limited to extending message queues to the cluster, I would be less
> concerned (although I feel it should be possible from user space).
As I have said before, DIPC is a config time option. You can decide if
you want it in your compiled kernel. What you say is like claiming it is
not a good idea to have all those driver sources in the Linux kernel just
because you won't be using most of them. Please think about this.
> An MPI programme is also MP-ready, but doesn't encourage constructs
> which are heavily penalised in a cluster. Thus MPI programmes written
> for SMP or DM machines (with fast interprocessor connections) should
> scale well to a cluster.
Yeah, but that works backwards: Creating a message passing layer on top of
a shared memory architecture. Shared memory is more fundamental. IMO an
appropriate "abstraction" should go the other way.
> Again: I'm all for abstractions that make life easier. But DSM makes
> people think the *wrong way* about distributed computing.
I'm repeating myself: Not everybody cares!
> And CS is littered with endless "ideas" which were dropped because
> they didn't work in real life. People moved on from those
> discussions. It cuts both ways.
I don't think continuing this discussion will convince any of us. Good
luck with your work.
-Kamran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/