Ocfs2 users - Feb 2007 - relation between ocfs2 1.2.4-2 and kernel.org GIT HEAD

dear OCFS2 gurus,
I have a dubt.... what is the relation between latest ocfs2 source,
e.g. 1.2.4-2, and kernel.org ocfs2,e.g. GIT head. ?
I mean, are they exactly the same ?
I suspect that:
1) as the 2.6.x in kernel API changes, you have to track it in the ocfs2 GIT
2) 1.2.4-2 is for vendor distros, so you code against a old-but-stable
kernel API
If the above is true, then those two codes are similar but not quite the same..
unless you use some thin sw layer to abstract from the kernel API

PS: I'd like to add a onerror=umount mount option. It'd be friendlier
in my environment, in which ocfs2 is used by a numerical computing
cluster which uses the SAN for both temporary and permanent data
storage

thanks in advance

-- 
davide.rossetti@gmail.com ICQ:290677265 SKYPE:d.rossetti

OCFS2 has two trees. The 1.2 tree and the git tree.

All new development happens on git head. All bug fixes are typically
worked on the tree that it was detected on. Later, the bug fix is applied
to the other tree. As most of our users are using the 1.2 tree, almost all
bug fixes flow from the 1.2 tree to the git tree.

As far as the current status of the trees go, most of the patches in 1.2.4
(post 1.2.3) could not make it in time for 2.6.20. They have since been
applied to the current git head. No, we cannot apply the patches to the
2.6.20 stable tree as the maintainers have very strict rules (some of the
patches are > 100 lines with context).

As we cannot go the stable tree route, we plan on making a branch
on ocfs2.git to allow 2.6.20 users to update their trees to 1.2.4. We
will send out an email with the details once that branch is ready,

onerror=umount will require vfs changes. Mark should be able to
expand on this.

davide rossetti wrote:
> dear OCFS2 gurus,
> I have a dubt.... what is the relation between latest ocfs2 source,
> e.g. 1.2.4-2, and kernel.org ocfs2,e.g. GIT head. ?
> I mean, are they exactly the same ?
> I suspect that:
> 1) as the 2.6.x in kernel API changes, you have to track it in the 
> ocfs2 GIT
> 2) 1.2.4-2 is for vendor distros, so you code against a old-but-stable
> kernel API
> If the above is true, then those two codes are similar but not quite 
> the same..
> unless you use some thin sw layer to abstract from the kernel API
>
> PS: I'd like to add a onerror=umount mount option. It'd be
friendlier
> in my environment, in which ocfs2 is used by a numerical computing
> cluster which uses the SAN for both temporary and permanent data
> storage
>
> thanks in advance
>