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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
