[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: 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+:


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

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?):

I also see that I already asked about the cloexec license once before,
and seemed to have consensus that LGPLv2+ wasn't an issue:

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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