Sunil Mushran wrote: > You do realize that the kernel is constantly changing and > it is not possible to keep one version of any component > compatible with the kernel without changing that too. > Ok, you already do that correct? Why prevent end users from compiling your source on the later kernels ( the ones that are compatible). From my original post, I was referring to the fact that it says we will not be able to compile the source on kernels it is compatible with.
> The only way we can keep the fs compatible with the kernel > is to keep updating the fs too. The version of the fs in the > kernel tree tracks the kernel. Then the source should be compatible too correct? > > The 1.2 tree is meant to work with few kernels only. As in, > EL and SLES. That's it. > Interesting. So you are saying that 1.2 only works with heavily patched kernels for only 2 distros? I just don't get that. If fact, I haven't too much of an issue so far compiling on different distros as long as I am able to find patches to your source that haven't been released or aren't contained within the provided source. > Randy Ramsdell wrote: >> Sunil Mushran wrote: >> >>> What's wrong with using ocfs2 bundled with the kernel? >>> >>> >> >> Top posting argh. >> >> I find that upgrading a "driver" by using a completely different kernel >> a little overkill. What happens when we need a better ocfs2 driver and >> the distro only has ocfs2 three versions back? Well, we build from >> source, and don't have to worry about downlading the latest kernel >> release, which doesn't include the patches that the distro has included >> which are sometimes needed. To upgrade to a recent version of ocfs2 on a >> distro that uses an old version requires that we abandon the distro >> kernel, download pristine kernel source, and compile/install from there. >> Once again this seems way overkill and somehow microsoft'ish. We need a >> driver and only the driver sometimes. This same problem exists with >> other software packages, such as spam, email virus detection or >> filesystem drivers that need to be upgraded more frequently than what I >> see currrently with most package based distros. As an example, the >> latest version we have currently available in the kernels we use is >> v1.2.3, but we run v1.2.5 since I compile and create rpms for them. I >> would really like to see the source remain compilable just in case we >> cannot upgrade the complete OS version or distro to one that contains a >> more recent ocfs2 version. >> >> Thanks, >> Randy Ramsdell >> >> >>> Randy Ramsdell wrote: >>> >>>> Hi, >>>> >>>> >From the main ocfs2 site, I read this. >>>> >>>> <quote> >>>> For users building from OCFS2 1.2.x tarballs >>>> <http://oss.oracle.com/projects/ocfs2/files/source/v1.2/> with kernels >>>> 2.6.14 or later, use the following make command: >>>> >>>> make GENERIC_DELETE_INODE_NOT_TRUNCATES=1 >>>> >>>> NOTE: OCFS2 1.2 does not build with kernels 2.6.20 or later. Use the >>>> version bundled with that kernel. All patch fixes for OCFS2 applicable >>>> to this kernel version and later are maintained here >>>> <http://www.kernel.org/pub/linux/kernel/people/mfasheh/ocfs2/backports/>. >>>> >>>> >>>> </quote> >>>> >>>> Does this mean that after systems upgrade to kernel 2.6.20 we will >>>> /only/ be able to use the kernel supplied ocfs2 version and must >>>> upgrade >>>> the kernel to use a newer release? >>>> >>>> Thanks, >>>> Randy Ramsdell >>>> >>>> _______________________________________________ >>>> Ocfs2-users mailing list >>>> [email protected] >>>> http://oss.oracle.com/mailman/listinfo/ocfs2-users >>>> >> >> > _______________________________________________ Ocfs2-users mailing list [email protected] http://oss.oracle.com/mailman/listinfo/ocfs2-users
