[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnulib broken on systems lacking fchdir

From: Matthew Woehlke
Subject: Re: gnulib broken on systems lacking fchdir
Date: Thu, 30 Nov 2006 11:53:23 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061025 Thunderbird/ Mnenhy/

Eric Blake wrote:
According to Matthew Woehlke on 11/29/2006 4:48 PM:
The licensing issue is a more important question; do any of the fchdir
users need to stay LGPL?

fts-lgpl already has licensing issues that have been brought up this
month, so I don't think you would be making matters any worse by writing a
GPL-only fchdir replacement.  But yes, if fts-lgpl is to work on platforms
lacking fchdir, then maybe we would have to consider making fchdir LGPL as

I have no problem making anything I write LGPL, especially as I expect it to be pretty trivial. The main issue would be gl_list (as per comments below), but maybe I'll just use that and call my code LGPL but with a GPL dependency. Then if anyone needs an LGPL fchdir, it'll be their problem to rip out gl_list and put in something else. :-)

As per the above comment, I don't think that is going to work, since
anyone editing the code then needs to know to use the fchdir-replacement
functions, which is of course a maintenance nightmare.

The other thing we could do, rather than writing "fchdir.h", is write a
replacement <unistd.h> that takes care of fchdir replacement, similar to
how we already have a replacement <inttypes.h>.  Then, modules that use
fchdir merely need to depend on the fchdir module, and all the magic is
taken care of _without any need to edit fchdir clients_.  That is what
makes gnulib so slick - between <config.h> and replacement headers,
remaining modules can behave as though the function always exists,
regardless of the deficiencies of the underlying platform.

That sounds like a good idea, but... does that mean I have to *write* an entire unistd.h *and* make it work everywhere, or is there a way to 'drop in' one that pulls the system unistd.h, plus extras?

Hmm, something I know absolutely nothing about, but at least it sounds
like something I can use safely ("safe" in the legal sense).

Actually, if you use gl_list, you MUST be GPL, since gl_list is GPL only.
 I guess that would mean that libraries that want to use fts-lgpl just
won't work on platforms that lack fchdir; fortunately, coreutils does not
suffer from the need to use LGPL or looser.

As mentioned, so far this has nothing to do with coreutils except that I know it *will* affect coreutils. Right now I'm worrying about gzip. :-) But... I'm also planning on building gettext (albeit not a version that has the newer *at stuff AFAIK). I don't *expect* anyone to be building non-GPL software using gettext (not on this platform, certainly!) but maybe 'better safe' would be preferable here.

Back to the technical standpoint, come to think of it don't most systems limit # of fd's to a reasonable number like 1024? IOW something that allocating a fixed array, even if it had to be large enough to hold all possible fd's, would not be unreasonable on modern (i.e. > 64 MB memory) systems? Else an indirection table (24:8 with the upper table dynamically sized) would certainly keep things under control. That would give O(1) access and deletion and O(1)*O(malloc()) (with average O(1)) insertion, without allocating one huge block of memory for a sparse list.

"Lost a planet, Obi Wan has? How embarassing..."
 -- Yoda (Star Wars II: Attack of the Clones)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]