>> Hi list,
>> Does anybody knows if it=B4s possible a OpenSSI cluster on SUSE SLES8?
>> thanks in advance.
I mostly lurk on this list, but my preferred distro is SuSE.
I don't think anyone has tried, or I would remember.
SuSE and Redhat have traditionally put things in different places.
ie. init.d has a different path on the different distros, I think
So I suspect it would not be trivial to do so.
OTOH, SuSE is moving towards using LSB defined paths I believe. If RH is doing =
the same, eventually the path issues will go away. Then the main issue will be =
the kernel.

Hi,
On Wed, 2003-04-16 at 00:21, John Byrne wrote:
> Aneesh Kumar K.V wrote:
> > Hi,
> >
> > With the changes to remove SIGCLUSTER I am getting Oops on my Alpha
> > during post-root cluster initialisation
> >
> > will update the list regarding the progress.
> >
> >
> > -aneesh
>
> Sigh. I was afraid of that. I did test ia64 before I checked in.
>
> Is it is in ssidev_discover_devfs()? I know I hit something related to
> the tools changes of "/cluster/nodeum to /cluster/node" at some point on
> my testing. I cannot remember the details just now, though.
>
I guess it has something to do with compiler. I was getting a weired
behaviour with kernel_thread_with_pid. Trying to print the function
address in kernel_thread_with_pid makes every thing work fine.
I will try everything again with a clean build.
-aneesh

Aneesh Kumar K.V wrote:
> We didn't hear from any of them. But there were two people who requested
> not to switch to Redhat kernel. So the voting is 2:0 :)
I'm not suggesting the entire OpenSSI project switch to the Red Hat
kernel. My concern is that I don't have enough time to support both the
vanilla and Red Hat kernels. I'm more interested in the Red Hat kernel,
so I'm choosing to support that.
The OpenSSI project is a community effort. If the community is
interested in supporting the vanilla kernel, then someone from the
community will step up to make sure it happens. :) I can help him/her by
describing the procedures I use to roll releases and merge changes from
one branch to another. After he demonstrates the quality of his work, I
can give him full admin access so he can support the vanilla kernel
without any help from me. Doing this is a good way for someone new to
contribute to the project, and it frees up my time to pursue what I want
to do. ;)
> That brings other problem. John has been really good at taking care of
> all architecture when moving to higher kernel releases. Whenever he does
> that he takes care of all the archs. ( Great work!!!).
If John doesn't merge with new vanilla kernels anymore, that just means
someone else will have to do it. :) It's not necessarily that difficult.
CVS does most of the work. For any difficult conflicts that arise during
the merge, I'm sure John, myself, or any other developer can offer
advice on how to resolve the conflict.
> Again from what others/projects are doing i see most of them working on
> vanilla linux kernel .
Most kernel projects are drivers and filesystems. I doubt they have
serious portability problems between vanilla and distribution-specific
kernels. Of those that are not drivers or filesystems, most only touch
one or two subsystems. Therefore it's not terribly difficult for a
talented user of an average kernel project to apply their patch against
a Red Hat kernel and get it to work.
OTOH, OpenSSI has to touch almost everything to create the illusion that
the cluster is a single machine. Without some knowledge about how
OpenSSI works, it's virtually impossible for the same user to accomplish
the same feat with its vanilla kernel patch. I know this because even
John had to take a few days to do the initial port to the RH kernel. ;)
> But One thing I would like to say is that, if you are sure that we can
> do early/frequent releases and easy installable STABLE RPMS by switching
> the redhat kernel, then my vote is to switch to redhat kernel. That make
> the voting result 2:1 ;-)
The RPM releases will definitely be much easier to do, which will allow
me to do them more often. Hopefully they will also be more stable. The
more development that's done on the RH branch, the more likely this will
be true. ;)
Brian