[Linux-cluster] GFS for Linux kernel 2.6.16

[Robert Peterson]

Hi Thomas,

Thomas Karsten wrote:
> When do you decide to develop for a new kernel? Couldn't you store the code
> in your releases directory and tag it before you start programming for a new
> kernel version? In this case you will always have working releases for
> various kernel versions.
>   
For development, we try to stay with the latest kernel defined by 
kernel.org in their
git repositories.  At some point, someone at a level above me has to 
draw a line in the
sand and freeze the kernels for both Fedora Core and the development 
versions of
Red Hat Enterprise Linux (RHEL).  The kernel.org kernels are so 
fast-moving that
it's usually a bit out of date when we freeze the kernel.  So we often 
have to keep
our own kernel patches so that the development code will compile against 
the frozen
Linux kernel.  Tagging it sounds like a good idea, but that whole 
process is done by
somebody else, so I don't know much about it.
> I know and I agree :-) Unfortunately I am using a Xen kernel and standard
> Xen builds only against version 2.6.16.
>   
We've got Xen building for 2.6.17 and probably 2.6.18, but again, that's 
someone
else, so I'm afraid I'm not much help there.
I just know that some people are testing the new code on Xen clusters, 
that is,
clusters that are virtual, i.e. running on the same physical box, 
through Xen,
or for example, dozens of virtual machines running from a few boxes on Xen.
> I agree. This would make it much easier to find the matching sources,
> especially for people who will download GFS for the first time (like me).
> Since a version of GFS is build against a special kernel version I was
> surprised that there is no identification of the source code (like the
> tagging that Matthew mentioned above).
>
> Thomas
>   
I agree that tagging the versions is a good idea.  I'll see if I can 
talk to the
build people about this.

Regards,

Bob Peterson
Red Hat Cluster Suite