lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MOSIX and kernel mods.
I couldn't agree more.

But I do think there is value there because DIPC and friends could be very
valuable as tools for developing applications that work better in a
distributed manner. If each section of code (thread, process) can operate
within the framework that DIPC, et al. provide then there is a good argument
for providing that functionality as an integrated part of the OS where things
like filesystems and process management and signalling can be coordinated with
the help of the kernel.

Richard Gooch wrote:

> Gerhard Mack writes:
> > It's a non issue anyhow if they have gone and changed the module
> > interface they will now have to spend the time making their patches work
> > for each and every kernal version or risk being outdated.
> >
> > That kind of time resource doesn't come cheaply.
> >
> > I don't see how anyone can see what they have done as an advantage for
> > themselves cause it sucks to be them. This is that binary module
> > compatabillity problem that was argued about x2 they now have to worry
> > about kernel module interface changes AND hope none affact their patch.
>
> Going hopefully more on-topic, I don't think MOSIX matters anyhow. I'm
> not convinced of the merit of the idea in the first place. If you want
> "nice" clustering support, you're probably better off with DIPC
> anyway, keeping more of it in user space (but still not all).
>
> And I'm not even convinced about the DIPC model either. I think trying
> to pretend a networked cluster of machines is really a single happy
> machine with lots of nodes is fundamentally flawed. The right way
> (IMNSHO) is to provide a flexible and lightweight API to support
> communications (in user space), and write your application *knowing*
> you're running on a networked cluster.
>
> Any abstraction that attempts to hide the immutable fact that
> inter-node latency is high and bandwidth is low is a *bad*
> abstraction. It lulls the programmer into thinking they're writing
> efficient code. Local nodes and remote nodes *should* be treated
> differently, because they *are* different.
>
> IMO MOSIX/DIPC is the wrong approach.
>
> I'll now stand back and hold out a few marshmallows...
>
> Regards,
>
> Richard....
>
> -
> 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/


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.058 / U:1.392 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site