[Unionfs] Changes in namei.h not consistent across releases

[Erez Zadok]

In message <47f55618.06025a0a.6ebe.ffffb297 at mx.google.com>, "Troy Volin" writes:
> Hi,
> I'm trying to build unionfs (most recently 2.3.2, but it doesn't
> matter) for kernel 2.6.18 (actually for RHEL 5, but we'll get to
> that...).
> There's a conflict between some of RedHat's Tux code (for in-kernel
> httpd server "Tux") and unionfs.
> I have just finished backing the Tux patches off of the RHEL5 kernel, (not 
> fun!) but I'm still curious about the necessity of doing so.
> 
> Meanwhile, I noticed that the conflict isn't present in unionfs patches for 
> every kernel version.
> The specific conflict is the definition of LOOKUP_ONE (value 128) for the 
> lookup event bitmask.
> 
> The patches for 2.6.23 and 2.6.24 do not (and have not) defined LOOKUP_ONE.
> They also omit the corresponding check for LOOKUP_ONE in fs/namei.c.
> 
> I could not find anywhere in the code where that flag was getting set, so 
> perhaps it was just ornamental anyway.
> 
> So my question is, is there something special that happened at 2.6.23 which 
> made LOOKUP_ONE unnecessary?  Or is it safe to remove that code
> from all the earlier releases (kernel releases, not unionfs releases) as 
> well?
> 
> Thanks,
> Troy

Troy, yes, the fs/namei.c code got changed between releases.  Usually we do
that when a new mainline kernel provides better VFS-level features, and
such.  In more recent kernels, for example, we were able to reduce the
amount of VFS-level changes that the unionfs patch performs.

Anyway, such a flag conflict can probably be resolved fairly easily.  If you
can get me a kernel source code tarball with all the patches applied, but
which doesn't compile for you, I'll look into it and send you a patch.

Alternatively, send me a link where I can find a tux patch for
2.6.18-vanilla and I'll check it here w/ my setup.

Cheers,
Erez.