[Ocfs2-users] ocfs2 custom builds

[Randy Ramsdell]

Mark Fasheh wrote:
> On Thu, Jul 19, 2007 at 10:38:17AM -0700, Sunil Mushran wrote:
>   
>> Randy Ramsdell wrote:
>>     
>>> 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.
>>>  
>>>       
>> Because it may not build.
>>     
>
> In fact, I'll add to that. You might be able to get it to build. However, it
> may not run completely as expected. Some patches just change things like
> locking expectations for a function, or return values. So applying them to
> your ocfs2 1.2 tree but running it on a kernel earlier than the one that
> made those changes could be harmful. If you're not very careful with
> reviewing the patches applied _and_ the changes to the kernel from where you
> got that patch, you could wind up with something that crashes unexpectedly,
> silently corrupts data, or hang.
>   
> Again, none of this is to say that ocfs2 1.2 could never ever be made to
> compile against a later kernel. My only point is that it's a much more
> involved process than you seem to imply and we simply don't have the
> resources to do that.
>   
My main question was not related to compiling ocfs2 v.oldversion on a
newer kernel. I was asking will source compile _at all _on a supported
kernel version such as 2.6.20 and not 2.6.20-patch level.  If  ocfs2
will compile and be considered stable on  an appropriate pristine kernel
source, then that negates the kernel upgrade I was refering to.  What I
have seen so far is newer versions of ocfs2 patched into the same kernel
version(prinstine) but not requiring a newer kernel version. Same kernel
but different distro patch level. When it does require a newer kernel
version, then  steps can be made to make that work as long as the source
will actually compile.
> The bottom line:
>
> Just because it builds, doesn't mean it'll run as well as expected. To test
> and verify the latter is much much more work than simply making gcc not
> throw an error.
> 	--Mark
>
>   
This does seem like the tricky part, but could be resolved by a source
comment stating so. Maybe the source package could state something like,
"this only works for kernel v.XXXXX unless we must consider the
particular distro's kernel patch level. At that point, we would know
what versions are compatible and could compile source within those
parameters and it would be considered stable.
> --
> Mark Fasheh
> Senior Software Developer, Oracle
> mark.fasheh at oracle.com
>   

Thanks for all the comments so far Mark, Sunil and Alexei.