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.
Richard Solis writes:
> 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.

Actually, I don't think we really agree. My view is that using
DIPC/MOSIX encourages bad programming and will hardly ever lead to
efficient parallel applications. Now if someone wants to write a user
space layer that gives them such a programming model, that's fine by
me.

But I'd object to even one nanosecond of extra latency or one byte of
kernel bloat to (exclusively) support such schemes, because I think
they're flawed. It's the same reason we don't want STREAMS in the
kernel. It's a flawed concept and it shouldn't bloat the kernel or
kill performance for sensible networking.

Now, if DIPC/MOSIX requires a kernel module and perhaps some system
calls, I don't mind if they are allocated some slots in the syscall
table (just like we did for STREAMS). But anything else should stay
out of the kernel.

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/

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