Will Mosix go into the standard kernel?

Will Mosix go into the standard kernel?

Post by Alexander Vir » Thu, 01 Mar 2001 06:40:07




> /proc/cluster/.... this would be standard root point for clustering stuff

> /proc/mosix would go away, become proc/cluster/mosix

> and the same with whatever bproc puts into /proc; that stuff would move to
> /proc/cluster/bproc

#include <std_rants/Thou_Shalt_Not_Shite_Into_Procfs>

Guys, if you want a large subtree in /proc - whack yourself over the head
until you realize that you want an fs of your own. I'll be more than
happy to help with both parts.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Rik van Rie » Thu, 01 Mar 2001 06:50:05



> I've thought that it would be good to break up the different
> clustering frills -- node identification, process migration,
> process hosting, distributed memory, yadda yadda blah, into
> separate bite-sized portions.

It would also be good to share parts of the infrastructure
between the different clustering architectures ...

Quote:> Is there a good list to discuss this on?  Is this the list?
> Which pieces of clustering-scheme patches would be good to have?

I know each of the cluster projects have mailing lists, but
I've never heard of a list where the different projects come
together to eg. find out which parts of the infrastructure
they could share, or ...

Since I agree with you that we need such a place, I've just
created a mailing list:


To subscribe to the list, send an email with the text
"subscribe linux-cluster" to:


I hope that we'll be able to split out some infrastructure
stuff from the different cluster projects and we'll be able
to put cluster support into the kernel in such a way that
we won't have to make the choice which of the N+1 cluster
projects should make it into the kernel...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

                http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by David L. Nico » Thu, 01 Mar 2001 06:30:05



> Just curious, are there any plans to put Mosix into the standard kernel,
> maybe in 2.5, so folks could just configure it and go? it seems that the
> number of people with more than one computer might make this a feature many
> would at least want to try, especially if it was available as an option by
> default. Is there anything in the Mosix folks' implementation that would
> prevent this?

I'm not a knowledgeable person, but I've been following Mosix/beowulf/? for
a few years and trying to keep up.

I've thought that it would be good to break up the different clustering
frills -- node identification, process migration, process hosting, distributed
memory, yadda yadda blah, into separate bite-sized portions.  

Centralization would be good for standardizing on what /proc/?/?/? you read to
find out what clusters you are in, and whatis your node number there.  There
is a lot of theorhetical work to be done.

Until then, I don't expect to see the Complete Mosix Patch Set available
from ftp.kernel.org in its current form, as a monolithic set that does many things,
including its Very Own Distributed File System Architecture.

If any of the work from Mosix will make it Into The Standard Kernel it will be
by backporting and standardization.

Is there a good list to discuss this on?  Is this the list?  Which pieces of
clustering-scheme patches would be good to have?

I think a good place to start would be node numbering.

The standard node numbering would need to be flexible enough to have one machine
participating in multiple clusters at the same time.

/proc/cluster/....      this would be standard root point for clustering stuff

/proc/mosix would go away, become proc/cluster/mosix

and the same with whatever bproc puts into /proc; that stuff would move to
/proc/cluster/bproc

Or, the status quo will endure, with cluster hackers playing catch-up.

--

             "Americans are a passive lot, content to let so-called
                              experts run our lives" -- Dr. Science

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Zack Brow » Thu, 01 Mar 2001 07:20:04


Do the Mosix folks have anything to add about possible integration into the
kernel? (should have cced them earlier, but it slipped my mind)



> > Just curious, are there any plans to put Mosix into the standard kernel,
> > maybe in 2.5, so folks could just configure it and go? it seems that the
> > number of people with more than one computer might make this a feature many
> > would at least want to try, especially if it was available as an option by
> > default. Is there anything in the Mosix folks' implementation that would
> > prevent this?

> I'm not a knowledgeable person, but I've been following Mosix/beowulf/? for
> a few years and trying to keep up.

> I've thought that it would be good to break up the different clustering
> frills -- node identification, process migration, process hosting, distributed
> memory, yadda yadda blah, into separate bite-sized portions.  

> Centralization would be good for standardizing on what /proc/?/?/? you read to
> find out what clusters you are in, and whatis your node number there.  There
> is a lot of theorhetical work to be done.

> Until then, I don't expect to see the Complete Mosix Patch Set available
> from ftp.kernel.org in its current form, as a monolithic set that does many things,
> including its Very Own Distributed File System Architecture.

> If any of the work from Mosix will make it Into The Standard Kernel it will be
> by backporting and standardization.

> Is there a good list to discuss this on?  Is this the list?  Which pieces of
> clustering-scheme patches would be good to have?

> I think a good place to start would be node numbering.

> The standard node numbering would need to be flexible enough to have one machine
> participating in multiple clusters at the same time.

> /proc/cluster/.... this would be standard root point for clustering stuff

> /proc/mosix would go away, become proc/cluster/mosix

> and the same with whatever bproc puts into /proc; that stuff would move to
> /proc/cluster/bproc

> Or, the status quo will endure, with cluster hackers playing catch-up.


|
|#include <std_rants/Thou_Shalt_Not_Shite_Into_Procfs>
|
|Guys, if you want a large subtree in /proc - whack yourself over the head
|until you realize that you want an fs of your own. I'll be more than
|happy to help with both parts.

Rik van Riel said:

- Show quoted text -

> I know each of the cluster projects have mailing lists, but
> I've never heard of a list where the different projects come
> together to eg. find out which parts of the infrastructure
> they could share, or ...

> Since I agree with you that we need such a place, I've just
> created a mailing list:


> To subscribe to the list, send an email with the text
> "subscribe linux-cluster" to:


> I hope that we'll be able to split out some infrastructure
> stuff from the different cluster projects and we'll be able
> to put cluster support into the kernel in such a way that
> we won't have to make the choice which of the N+1 cluster
> projects should make it into the kernel...

--
Zack Brown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by J . A . Magallo » Thu, 01 Mar 2001 07:50:04



Quote:> Do the Mosix folks have anything to add about possible integration into the
> kernel? (should have cced them earlier, but it slipped my mind)


--
J.A. Magallon                                                      $> cd pub

Linux werewolf 2.4.2-ac5 #1 SMP Tue Feb 27 01:09:47 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by zbr.. » Thu, 01 Mar 2001 07:50:04


argh. OK


> Do the Mosix folks have anything to add about possible integration into the
> kernel? (should have cced them earlier, but it slipped my mind)



> > > Just curious, are there any plans to put Mosix into the standard kernel,
> > > maybe in 2.5, so folks could just configure it and go? it seems that the
> > > number of people with more than one computer might make this a feature many
> > > would at least want to try, especially if it was available as an option by
> > > default. Is there anything in the Mosix folks' implementation that would
> > > prevent this?

> > I'm not a knowledgeable person, but I've been following Mosix/beowulf/? for
> > a few years and trying to keep up.

> > I've thought that it would be good to break up the different clustering
> > frills -- node identification, process migration, process hosting, distributed
> > memory, yadda yadda blah, into separate bite-sized portions.  

> > Centralization would be good for standardizing on what /proc/?/?/? you read to
> > find out what clusters you are in, and whatis your node number there.  There
> > is a lot of theorhetical work to be done.

> > Until then, I don't expect to see the Complete Mosix Patch Set available
> > from ftp.kernel.org in its current form, as a monolithic set that does many things,
> > including its Very Own Distributed File System Architecture.

> > If any of the work from Mosix will make it Into The Standard Kernel it will be
> > by backporting and standardization.

> > Is there a good list to discuss this on?  Is this the list?  Which pieces of
> > clustering-scheme patches would be good to have?

> > I think a good place to start would be node numbering.

> > The standard node numbering would need to be flexible enough to have one machine
> > participating in multiple clusters at the same time.

> > /proc/cluster/....    this would be standard root point for clustering stuff

> > /proc/mosix would go away, become proc/cluster/mosix

> > and the same with whatever bproc puts into /proc; that stuff would move to
> > /proc/cluster/bproc

> > Or, the status quo will endure, with cluster hackers playing catch-up.


> |
> |#include <std_rants/Thou_Shalt_Not_Shite_Into_Procfs>
> |
> |Guys, if you want a large subtree in /proc - whack yourself over the head
> |until you realize that you want an fs of your own. I'll be more than
> |happy to help with both parts.

> Rik van Riel said:

> > I know each of the cluster projects have mailing lists, but
> > I've never heard of a list where the different projects come
> > together to eg. find out which parts of the infrastructure
> > they could share, or ...

> > Since I agree with you that we need such a place, I've just
> > created a mailing list:


> > To subscribe to the list, send an email with the text
> > "subscribe linux-cluster" to:


> > I hope that we'll be able to split out some infrastructure
> > stuff from the different cluster projects and we'll be able
> > to put cluster support into the kernel in such a way that
> > we won't have to make the choice which of the N+1 cluster
> > projects should make it into the kernel...

> --
> Zack Brown

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
--
Zack Brown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Will Mosix go into the standard kernel?

Post by Ric Wheele » Fri, 02 Mar 2001 03:10:05


There are two parts of MOSIX that deal with file systems.
In MOSIX, every migrated process leaves a proxy at its creation (home)
node that services all system call requests, including IO calls.

What newer versions of MOSIX did is to add the "DFSA" (direct file
system access) layer that allows MOSIX to support executing file
system calls locally for migrated process when they are against a
cache coherent, cluster file system (think GFS).  When this was put
in MOSIX, they also did a write through, non-caching file system to
test their DFSA code called MFS.

Both the MOSIX team and the global file system group have been involved
in getting their stuff to play nicely together.

ric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Daniel Ridg » Fri, 02 Mar 2001 08:10:04


Fellow Beowulfers,

I have yet to hear a compelling argument about why any of them should
go into the standard kernel -- let alone a particular one or a duck of a
compromise.

The Scyld system is based on BProc -- which requires only a 1K patch to
the kernel. This patch adds 339 net lines to the kernel, and changes 38
existing lines.

The Scyld 2-kernel-monte kernel inplace reboot facility is a 600-line
module which doesn't require any patches whatsoever.

Compare this total volume to the thousands of lines of patches that
RedHat or VA add to their kernel RPMS before shipping. I just don't see
the value in fighting about what clustering should 'mean' or picking
winners when it's just not a real problem.

Scyld is shipping a for-real commercial product based on BProc and
2-kernel-Monte and our better-than-stock implementation of LFS and and
we're not losing any sleep over this issue.

I think we should instead focus our collective will on removing things
from the kernel. For years, projects like ALSA, pcmcia-cs, and VMware
have done an outstanding job sans 'inclusion' and we should more
frequently have the courage to do the same. RedHat and other linux vendors
have demonstrated ably that they know how to build and package systems
that draw together these components in an essentially reasonable way.

Regards,
        Dan Ridge
        Scyld Computing Corporation



> > I've thought that it would be good to break up the different
> > clustering frills -- node identification, process migration,
> > process hosting, distributed memory, yadda yadda blah, into
> > separate bite-sized portions.

> It would also be good to share parts of the infrastructure
> between the different clustering architectures ...

> > Is there a good list to discuss this on?  Is this the list?
> > Which pieces of clustering-scheme patches would be good to have?

> I know each of the cluster projects have mailing lists, but
> I've never heard of a list where the different projects come
> together to eg. find out which parts of the infrastructure
> they could share, or ...

> Since I agree with you that we need such a place, I've just
> created a mailing list:


> To subscribe to the list, send an email with the text
> "subscribe linux-cluster" to:


> I hope that we'll be able to split out some infrastructure
> stuff from the different cluster projects and we'll be able
> to put cluster support into the kernel in such a way that
> we won't have to make the choice which of the N+1 cluster
> projects should make it into the kernel...

> regards,

> Rik
> --
> Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...

>            http://www.surriel.com/
> http://www.conectiva.com/    http://distro.conectiva.com/

> _______________________________________________

> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Will Mosix go into the standard kernel?

Post by Albert D. Cahala » Fri, 02 Mar 2001 09:50:03


Quote:Daniel Ridge writes:
> Fellow Beowulfers,

> I have yet to hear a compelling argument about why any of them should
> go into the standard kernel -- let alone a particular one or a duck of a
> compromise.

> The Scyld system is based on BProc -- which requires only a 1K patch to
> the kernel. This patch adds 339 net lines to the kernel, and changes 38
> existing lines.

Well, that explains your viewpoint and your motivation. :-)

Quote:> I think we should instead focus our collective will on removing things
> from the kernel. For years, projects like ALSA, pcmcia-cs, and VMware

ALSA: driver work gets done twice

pcmcia-cs: this was so bad that Linus himself was unable to install
Linux on his new laptop, so now PCMCIA support is in the kernel.

VMware: quite a pain I think

You are basically suggesting the often-rejected "split up the kernel"
idea. I think the linux-kernel FAQ covers this.

Quote:> have done an outstanding job sans 'inclusion' and we should more
> frequently have the courage to do the same. RedHat and other linux vendors
> have demonstrated ably that they know how to build and package systems
> that draw together these components in an essentially reasonable way.

So people should only get kernels from linux vendors? This is great
for your business I'd imagine, but one of the nice things about Linux
is that you can replace the kernel without too much trouble.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Will Mosix go into the standard kernel?

Post by Dan Holli » Fri, 02 Mar 2001 10:00:05



> Daniel Ridge writes:
> > I think we should instead focus our collective will on removing things
> > from the kernel. For years, projects like ALSA, pcmcia-cs, and VMware
> ALSA: driver work gets done twice

Huh?

-Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Daniel Ridg » Fri, 02 Mar 2001 10:50:04



> > The Scyld system is based on BProc -- which requires only a 1K patch to
> > the kernel. This patch adds 339 net lines to the kernel, and changes 38
> > existing lines.

> Well, that explains your viewpoint and your motivation. :-)

I would put this the other way around. I would say that Scyld reflects the
views of its core developers -- not the other way around. Those of us who
worked on the Beowulf project at NASA felt then exactly as we do today.

Quote:> ALSA: driver work gets done twice

It's an irrelevant detail if only one works. I've used the kernel's
brand of sound support and it mostly works. I'm usually too lazy
to get ALSA. I only use it when the kernel's support hasn't quite caught
up to ALSA's

Quote:> pcmcia-cs: this was so bad that Linus himself was unable to install
> Linux on his new laptop, so now PCMCIA support is in the kernel.

I often have exactly inverted problems with CardBus.

It's true that external packages often start to look like geologic rock
samples -- the sediment record of linux -- and that they become a record
of the things that have changed. Funniest, I think, is when these packages
record interfaces that merely churn without improving.

Naturally, it takes work to created a supportable piece of system software
that can be used on a number of platforms. I would also cite from your
text above: "driver work gets done twice".

Quote:> VMware: quite a pain I think

I think not! Installing VMware today is a breeze. SMP or UP? No problem!
Upgrade your kernel? No problem! Outstanding for a commercial third-party
application that happens to be available on two different platforms.

I would also add Myricom's GM package for Myrinet to the list of
reasonable components that are maintained outside of the kernel.
Vendors should be encouraged to provide the kind of commitment to linux
that Myri consistiently demonstrates.

Quote:> You are basically suggesting the often-rejected "split up the kernel"
> idea. I think the linux-kernel FAQ covers this.

No. I'm stipulating that I work with a really interesting piece of
software that works with the Linux kernel and is available under the GPL
and which we have never even bothered to 'submit' as a patch. I'm willing
to suggest further that any responsible development community is
suceptible to "race conditions" whereby the natural and studied
development and evaluation process is end-run by attempts to 'win' and
urinate on the kernel or ANSI or POSIX or whoever (with a facility or
mechanism) directly.

These types of 'hacks' or 'denials-of-service' play on the adage that
forgiveness is easier than permission. It's hard to dispute this point
in an age when SourceForge makes it possible for anyone to maintain
a driver or filesystem or whatever without needing to 'hitch a ride'
on an existing project (ala linux) that already has a distribution and
mirroring facility.

Quote:> So people should only get kernels from linux vendors? This is great
> for your business I'd imagine, but one of the nice things about Linux
> is that you can replace the kernel without too much trouble.

No. My point was that it is possible to do a reasonable job and that
building a kernel and subsytems so that the result is deliverable and
supportable is very hard -- harder than building a kernel and ALSA
for just yourself -- and that external components can be resonably done
even in the tough vendor environment.

From my own perspective, I'm far to lazy to build kernels for
myself. I can hack on Beowulf clustering -- including new kernel modules
-- all day long and the build process usually lasts 5s of seconds.

Regards,
        Dan Ridge
        Scyld Computing Corporation

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by zbr.. » Fri, 02 Mar 2001 11:50:03



> Fellow Beowulfers,

> I have yet to hear a compelling argument about why any of them should
> go into the standard kernel -- let alone a particular one or a duck of a
> compromise.

> The Scyld system is based on BProc -- which requires only a 1K patch to
> the kernel. This patch adds 339 net lines to the kernel, and changes 38
> existing lines.

> The Scyld 2-kernel-monte kernel inplace reboot facility is a 600-line
> module which doesn't require any patches whatsoever.

> Compare this total volume to the thousands of lines of patches that
> RedHat or VA add to their kernel RPMS before shipping. I just don't see
> the value in fighting about what clustering should 'mean' or picking
> winners when it's just not a real problem.

Where is the value in a bunch of incompatible alternatives that have to
be laboriously ported to each new kernel version, the patches growing ever
larger as the official sources gradually diverge?

I see your point about not wanting to standardize too quickly, and I agree. But
what is the harm in *talking* about it? Why not find out if some standard kernel
clustering API could be useful, instead of just rejecting the idea out of hand?

Maybe it's my fault as the originator of this thread, for asking if _MOSIX_
would ever be included. I certainly don't think MOSIX should be favored over
other clustering implementations, it just happens to be the one I think about
most often.

I think one compelling argument in favor of including some kind of clustering
API in Linux is to encourage folks to use it and hack on it. Then we can
spawn Wintermute and become blind slaves to its awesome power.

Quote:

> Scyld is shipping a for-real commercial product based on BProc and
> 2-kernel-Monte and our better-than-stock implementation of LFS and and
> we're not losing any sleep over this issue.

> I think we should instead focus our collective will on removing things
> from the kernel. For years, projects like ALSA, pcmcia-cs, and VMware
> have done an outstanding job sans 'inclusion' and we should more
> frequently have the courage to do the same. RedHat and other linux vendors
> have demonstrated ably that they know how to build and package systems
> that draw together these components in an essentially reasonable way.

Where do you draw the line? Maybe the developers should take SMP out of the
kernel, so the different vendors can all implement their favorite versions
without any ducks of compromise. (and don't tell me there is only one
universally accepted best way to implement SMP)

Be well,
Zack

- Show quoted text -

> Regards,
>    Dan Ridge
>    Scyld Computing Corporation



> > > I've thought that it would be good to break up the different
> > > clustering frills -- node identification, process migration,
> > > process hosting, distributed memory, yadda yadda blah, into
> > > separate bite-sized portions.

> > It would also be good to share parts of the infrastructure
> > between the different clustering architectures ...

> > > Is there a good list to discuss this on?  Is this the list?
> > > Which pieces of clustering-scheme patches would be good to have?

> > I know each of the cluster projects have mailing lists, but
> > I've never heard of a list where the different projects come
> > together to eg. find out which parts of the infrastructure
> > they could share, or ...

> > Since I agree with you that we need such a place, I've just
> > created a mailing list:


> > To subscribe to the list, send an email with the text
> > "subscribe linux-cluster" to:


> > I hope that we'll be able to split out some infrastructure
> > stuff from the different cluster projects and we'll be able
> > to put cluster support into the kernel in such a way that
> > we won't have to make the choice which of the N+1 cluster
> > projects should make it into the kernel...

> > regards,

> > Rik
> > --
> > Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

> > Virtual memory is like a game you can't win;
> > However, without VM there's truly nothing to lose...

> >               http://www.surriel.com/
> > http://www.conectiva.com/       http://distro.conectiva.com/

> > _______________________________________________

> > To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
--
Zack Brown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
 
 
 

Will Mosix go into the standard kernel?

Post by Tor Arnts » Sat, 03 Mar 2001 00:10:04


[...]
Quote:>Compare this total volume to the thousands of lines of patches that
>RedHat or VA add to their kernel RPMS before shipping. I just don't see

[...]

What's good about that?  The first thing I do is to rip out the RedHat
kernel and compile and install a pure kernel from ftp.kernel.org.
It's *bad* that those vendors deliver hacked kernels.  It's not
something that should be recommended as a *goal*!
When I need a new kernel version I can't sit back and hope with
crossed fingers that RedHat (or whatever vendor) comes out with a
new, hacked version of Linus' latest.

-Tor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Tim Wrigh » Sat, 03 Mar 2001 04:30:03




> [...]
> >Compare this total volume to the thousands of lines of patches that
> >RedHat or VA add to their kernel RPMS before shipping. I just don't see
> [...]

> What's good about that?  The first thing I do is to rip out the RedHat
> kernel and compile and install a pure kernel from ftp.kernel.org.

What's good is the added value that their customers gain. If you don't feel
there is any, then you're probably running the wrong distribution. The nice
thing with Linux is that you are free to go and grab your own kernel if you
wish to do so.

Quote:> It's *bad* that those vendors deliver hacked kernels.  It's not
> something that should be recommended as a *goal*!

No it isn't. You seem to assume that your requirements match everybody elses.
This is highly unlikely. A particular vendor will have a number of requirements
for their distribution (hopefully driven by customer demand). At the time that
they create a distribution, it's quite possible that no current pure kernel
meets those requirements. It's perfectly reasonable for a vendor to make
changes to meet those requirements, provided they abide by the licensing
demands. For instance, one major change in Red Hat 7.0 is that the kernel
supports USB. At the time, 2.4 wasn't ready and 2.2 didn't have support. What
do you suggest they should have done ?
The source code to the kernel that Red Hat ships is readily available, so I
fail to see why shipping a modified kernel is such a big issue.

Quote:> When I need a new kernel version I can't sit back and hope with
> crossed fingers that RedHat (or whatever vendor) comes out with a
> new, hacked version of Linus' latest.

Commercial customers rarely "require a new kernel version". They may encounter
problems that require fixing the kernel, but otherwise, they frequently couldn't
care less about the kernel. In such cases, they need some form of support.
There's nothing to suggest that a vendor-modified kernel is inherently harder
to support, provided that it doesn't diverge too radically.

Most people buy computers to run applications, not
an operating system. Those of us who do work on OS's are in the distinct
minority. Given that Linus works on the development kernel, wanting to run
on "Linus' latest" implies you're not using Linux in production or that you're
very brave :-)

Regards,

Tim

--

IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Will Mosix go into the standard kernel?

Post by Tor Arnts » Sat, 03 Mar 2001 19:30:05



[discussion about commercial customers and kernels snipped]

I don't think we disagree, actually.  My point was a different one.
With vendor-patched kernels you can either stick to the hacked kernel
or you can move on to an ftp.kernel.org kernel.  For the type of hacks
that RedHat & co are doing it shouldn't matter.  If it did, I mean if
they deliver hacked software that only works with a hacked kernel,
*then* I would be angry.  That would mean that I would have to track
the patches they did, and apply them myself to new kernels.  OR I
would have to sit back and wait for them to come out with an updated
distro, sometime in the future.  Not good.

What was brought up in this discussion about clustering patches was
that that kind of model would be a good idea.  I disagree.  One thing
is to deliver patches because integration is not currently possible, or
practical, or whatever, but to point to the RedHat hacked-kernels-are-us
model as a *goal*, that's what I don't like.  It's sometimes a necessity,
but it's not something that should be encouraged.

Cheers,
-Tor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. LCSDNYR 2001 -> standards, standards, standards

[snip - a call for standardisation]

I completely agree, but I don't think Linux is going the wrong way (yet).

As always, tarballs (./configure, make, su -c 'make install') stay (oh yes
they will). Package-like installing (cfr deb, rpm, jbl, ...) goes the
right way: easy, user-friendly and without any hassle. I don't think it's
necessary to evolve to one package. Each type of packaging has it
advantages and disadvantages. It's a choice, a mindgame if you will. Some
people like the deb-packages since they are extremely easy to install.
Some others want rpm, since the availability of those files is enormous.
Some people stay with the tarballs.

I don't think Linux is going the wrong way.

With packages without any hassle. With tarballs you should look at the
Makefile before 'make install'-ing and search for 'make uninstall'. If
that's available (and correctly programmed), there isn't any other hassle.

This could be one point of discussion (tarballs - uninstalling software),
but I don't know enough about tarballs (I only use them if I can't find
any rpm-files for it) so I'd better shut up :-/

Again, with packages no troubles. Tarballs are also without any hassle,
since upgrading is very simpel. Configuration-files stay (thus not the way
M$ handled things, i.e. registry), binaries get upgraded, libraries are
... how do they say it... renewed? I mean, a newer version of library
doesn't overwrite things (f.i. libsmpg-2.0-3.so.2), only has a greater
version-number (f.i. libsmpg-2.1-1.so.2). And ldconfig makes sure programs
use the right library...

/etc/*.conf, $HOME/.*rc, ... I think Linux (and most unix-like OS'ses) are
doing a great job on that. They are easy to back-up, easy to modify
(manually AND with scripts/tools), ...

--
 SwifT

2. OS type at compile time

3. Going, going, going, GONE! Bye Windows!

4. CD recording

5. cow goes moo moo, kernel goes oink oink

6. Q: mp3 player for X

7. coming from pppoe mode, going to "standard" Lan mode

8. VGA question

9. linux standard base going too slow?

10. Solaris on Intel: Going, going - Gone!

11. Enlightenment icon box- gone, gone, gone...

12. Solaris on Intel: Going, going - Gone!

13. redirecting standard output and standard error