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
[email protected]
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
