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
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
