Eric Blake wrote:
> 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 modu
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 f
On 12/10/2010 08:04 PM, Bruno Haible wrote:
> Hi Eric,
>
>> cloexec (currently LGPLv3+), fcntl (currently LGPLv3+).
>> Are there any objections to relaxing the license?
>
> Fine with me. lib/fcntl.c contains some originally GPLed code from me
> (the DuplicateHandle stuff: originally in lib/w32sp
On 12/11/2010 12:36 AM, Eric Blake wrote:
Jim, Bruno, and Paolo,
I want to eventually get to the point where open(O_CLOEXEC) can be
supported in gnulib for use in libraries like LGPLv2+ libvirt. Along
the way, I will want to make open (LGPLv2+) depend on cloexec (currently
LGPLv3+), which in tu
Eric Blake wrote:
> Jim, Bruno, and Paolo,
>
> I want to eventually get to the point where open(O_CLOEXEC) can be
> supported in gnulib for use in libraries like LGPLv2+ libvirt. Along
> the way, I will want to make open (LGPLv2+) depend on cloexec (currently
> LGPLv3+), which in turn is a thin wr
Hi Eric,
> cloexec (currently LGPLv3+), fcntl (currently LGPLv3+).
> Are there any objections to relaxing the license?
Fine with me. lib/fcntl.c contains some originally GPLed code from me
(the DuplicateHandle stuff: originally in lib/w32spawn.h under GPL,
moved to lib/cloexec.c on 2009-12-05, b
On 12/10/2010 03:36 PM, Eric Blake wrote:
> Are there any objections to relaxing the license?
None here.
By the way, it bugs me a bit that in the normal
(e.g., Linux or Solaris) case, set_cloexec_flag
issues two system calls when one would do. Could
this be fixed at some point? One advantage o
Jim, Bruno, and Paolo,
I want to eventually get to the point where open(O_CLOEXEC) can be
supported in gnulib for use in libraries like LGPLv2+ libvirt. Along
the way, I will want to make open (LGPLv2+) depend on cloexec (currently
LGPLv3+), which in turn is a thin wrapper around fcntl (currently
