[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: relax license of cloexec, fcntl
From: |
Eric Blake |
Subject: |
Re: relax license of cloexec, fcntl |
Date: |
Mon, 13 Dec 2010 12:24:41 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
On 12/13/2010 10:04 AM, Eric Blake wrote:
> Yes, this point has been raised in the past. I certainly agree that a
> process with no children doesn't need the overhead of guaranteeing an
> open() wrapper that supports O_CLOEXEC, so definitely splitting things
> into two modules is worthwhile. In fact, I'm wondring if the best
> approach might even be to just have the existing cloexec module be the
> key for whether O_CLOEXEC is guaranteed to be supported in open.
>
> At any rate, all contributors have replied, so I'm pushing this:
Also worth converting from LGPLv3+ to LGPLv2+:
dup3
pipe2
accept4
I'm guessing they were created LGPL at the time because fcntl() and
cloexec modules were not at v2+. Any objections to relaxing those three
modules?
In fact, relaxing dup3 would allow me to implement fcntl(FD_SETFD) on
mingw by using dup_cloexec to a temporary, then dup3 to clone the
temporary on top of the target fd, and thus fix the problem where
cloexec's set_cloexec_flag() doesn't currently work on mingw.
I also found the thread was where I first laid out a plan for O_CLOEXEC
support (has it really been more than a year, and I still haven't
finished it?):
http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00260.html
I also see that I already asked about the cloexec license once before,
and seemed to have consensus that LGPLv2+ wasn't an issue:
http://lists.gnu.org/archive/html/bug-gnulib/2009-12/msg00106.html
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature