Compatability: aufs-utils needs GNU extensions to nftw

Compatability: aufs-utils needs GNU extensions to nftw

[idunham]

One of the Puppy developers recently mentioned that he'd like to build
mount.aufs with musl because the static binary is excessively large (600
kb) when built with glibc.
However, there are a couple issues:
1. The most important issue is that libau uses the following flags/macros:
FTW_ACTIONRETVAL
FTW_CONTINUE
FTW_SKIP_SUBTREE
FTW_SKIP
From all I can see, this would require some extensions to nftw() and
possibly  to fn().
I'm not sure exactly what glibc does with these, so I have no idea what to
do.

2. There's also a problem with a couple files using the GNU extension
<error.h>/error_at_line(); this is fairly readily hacked around.

3. AUFS does want a patched kernel; if you would rather just see about
building the tools without patching the kernel, get aufs3-standalone and
add ${AUFS3_STANDALONE}/include to the header search path so you have
<linux/aufs_type.h>

Thanks,
Isaac Dunham

Re: Compatability: aufs-utils needs GNU extensions to nftw

[Rich Felker]

On Tue, Jan 01, 2013 at 02:33:36PM -0800, idunham@lavabit.com wrote:
> One of the Puppy developers recently mentioned that he'd like to build
> mount.aufs with musl because the static binary is excessively large (600
> kb) when built with glibc.
> However, there are a couple issues:
> 1. The most important issue is that libau uses the following flags/macros:
> FTW_ACTIONRETVAL
> FTW_CONTINUE
> FTW_SKIP_SUBTREE
> FTW_SKIP

Are you sure it really _needs_ them? They seem to be mostly
optimizations to avoid walking uninteresing parts of the tree, and it
should be possible to achieve the same behavior (aside from time
wasted walking uninteresting stuff) with minor changes to the callback
function...

> >From all I can see, this would require some extensions to nftw() and
> possibly  to fn().
> I'm not sure exactly what glibc does with these, so I have no idea what to
> do.

This doesn't seem so bad, and probably could be added. But I'd like to
overhaul ftw anyway to use the *at functions instead of concatenating
paths, and to avoid recursion, and to handle the fd limit right. At
present I would say we have a very poor implementation. On the bright
side, these functions are so bad that correct software should not be
using them; they don't pass any context back to the callback, so the
only way to use them is with global or thread-local vars...

Rich

Re: Compatability: aufs-utils needs GNU extensions to nftw

[James B]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

I am the developer Isaac was talking about.

On Wed, Jan 2, 2013 at 12:27 PM, Rich Felker <dalias@aerifal.cx> wrote:

>
> Are you sure it really _needs_ them? They seem to be mostly
> optimizations to avoid walking uninteresing parts of the tree, and it
> should be possible to achieve the same behavior (aside from time
> wasted walking uninteresting stuff) with minor changes to the callback
> function...
>
> You are right that they are optimisations; that would be my guess too. The
utilities need to scan through all directories and files on multiple
filesystems - the more layer added to aufs, the worse it would be. Thus it
needs any optimisation it can get. I'm not the author of aufs-utils so I
can't be so sure.

Right now I managed to get it compiled with uclibc so at least the size
problem is resolved in the interim, but I prefer to use musl if possible.

cheers!
James

[-- Attachment #2: Type: text/html, Size: 1228 bytes --]