From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2531 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Compatability: aufs-utils needs GNU extensions to nftw Date: Tue, 1 Jan 2013 20:27:30 -0500 Message-ID: <20130102012730.GR20323@brightrain.aerifal.cx> References: <14643.50.0.224.127.1357079616.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1357090063 2541 80.91.229.3 (2 Jan 2013 01:27:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Jan 2013 01:27:43 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2532-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 02 02:28:00 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TqD7f-00010T-6b for gllmg-musl@plane.gmane.org; Wed, 02 Jan 2013 02:27:59 +0100 Original-Received: (qmail 7608 invoked by uid 550); 2 Jan 2013 01:27:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7600 invoked from network); 2 Jan 2013 01:27:43 -0000 Content-Disposition: inline In-Reply-To: <14643.50.0.224.127.1357079616.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2531 Archived-At: 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