On 30/06/12 04:23, Jonathan Nieder wrote: > When did O_CLOEXEC get involved? This report was about a use of > FD_CLOEXEC.
I've been *assuming* (as the only thing that makes sense) the situation is something like: Enabling FD_CLOEXEC on an open fd was previously not implemented (in the upstream kernel that we shipped with squeeze). So I think O_CLOEXEC is considered as zero such that: sink = open("/dev/null", O_WRONLY) is taken by our kernels to imply O_CLOEXEC unconditionally. Any fcntl() trying to enable it later would be a no-op. But Stefan was trying to run a GNU/kFreeBSD userland on an upstream FreeBSD kernel with FD_CLOEXEC support. This won't assume an implicit O_CLOEXEC, yet our glibc still doesn't know how to enable FD_CLOEXEC and returns an error. So I suppose there might be a way to implement FD_CLOEXEC (to cater for this special case) without implementing the O_CLOEXEC option yet. If any of the above was a correct assumption. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org