On Sunday 06 September 2009 11:01:26 Denys Vlasenko wrote: > On Sunday 06 September 2009 16:44, Mike Frysinger wrote: > > On Sunday 06 September 2009 06:07:04 Denys Vlasenko wrote: > > > On Sunday 06 September 2009 08:18, Mike Frysinger wrote: > > > > On Saturday 05 September 2009 18:05:32 Denys Vlasenko wrote: > > > > > On Saturday 05 September 2009 23:55, Mike Frysinger wrote: > > > > > > On Saturday 05 September 2009 17:55:26 Denys Vlasenko wrote: > > > > > > > >On Saturday 05 September 2009 16:04:36 Denys Vlasenko wrote: > > > > > > > >> +#ifndef O_CLOEXEC > > > > > > > >> +# define O_CLOEXEC 0 > > > > > > > >> +#endif > > > > > > > > > > > > > > > >it should be defined by the C library headers. if it isnt, > > > > > > > > then the port needs updating and the build should fail. so > > > > > > > > please drop this cruft. > > > > > > > > > > > > > > You probably was thinking about FD_CLOEXEC. :) > > > > > > > > > > > > > > Yes, FD_CLOEXEC must exist. > > > > > > > > > > > > > > O_CLOEXEC is a new, Linux specific open() flag. > > > > > > > And currently it is not yet defined, since there are many > > > > > > > old kernels in the wild which won't understand that. > > > > > > > > > > > > no, i'm thinking of O_CLOEXEC. i know what the flag is for, and > > > > > > it should be defined in bits/fcntl.h for every port. > > > > > > > > > > Currently, it is not defined on any arch: > > > > > > > > then you fix/update the arches instead of ignoring the problem and > > > > sprinkling cruft everywhere > > > > > > Defining O_CLOEXEC does not necessarily make it work. > > > Kernel should be new enough to understand it. > > > > > > If the program will be run on an old kernel, open() with O_CLOEXEC > > > will not work as expected. > > > > it'll work just fine. read lkml about open() behavior and unknown open() > > flags (tip: they get silently ignored). > > Yes. > > But this is not what expected. We do want those fd's to be closed on exec. > If we feed O_CLOEXEC to open and it gets ignored, we have non-CLOEXEC fd > and then we get stray fds in child processes. Not good. > > When I saw O_CLOEXEC ifdefed out in the headers, I understood it like > "we will enable it later, when O_CLOEXEC-enabled kernels will be widely > deployed". I think it's a correct approach. > > Another way is if we make it a uclibc config option "assume O_CLOEXEC > works". > > Unconditional usage of it would be dangerous right now, IMO.
this concern doesnt change anything wrt what i've said. if you want to handle this case, use the __ASSUME_* framework like everyone else. i.e. copy the definition of __ASSUME_O_CLOEXEC from glibc into our kernel-features.h and use that to determine whether you need to use fcntl() manually. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
