Re: [PATCHv2 4/4] first use of sys_indirect system call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dean gaudet wrote: > i'm not suggesting the library set the global flag. i'm suggesting that > me as an app writer will do so. > > it seems like both methods are useful. No, the global flag is hardly ever useful. You almost never know the details of all the libraries you link to well enough to determine that they don't need FD_CLOEXEC disabled. Even more problematic, you cannot know whether they will need it in future. For applications the solution is simple: wrap to appropriate calls. Apache has all these apr_ wrappers. But them to some good news after all. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHPeim2ijCOnn/RHQRAu8xAJsF/0Ir1PWMbHkVRaI5vKOGFS4tMACfVEs9 pMYAiCAU1E2B+7QR0EP+/F8= =btt9 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
On Fri, 16 Nov 2007, Ulrich Drepper wrote: > dean gaudet wrote: > > honestly i think there should be a per-task flag which indicates whether > > fds are by default F_CLOEXEC or not. my reason: third party libraries. > > Only somebody who thinks exclusively about applications as opposed to > runtimes/libraries can say something like that. Library writers don't > have the luxury of being able to modify any global state. This has all > been discussed here before. only someone who thinks about writing libraries can say something like that. you've solved the problem for yourself, and for well written applications, but not for the other 99.% of libraries out there. i'm not suggesting the library set the global flag. i'm suggesting that me as an app writer will do so. it seems like both methods are useful. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dean gaudet wrote: > honestly i think there should be a per-task flag which indicates whether > fds are by default F_CLOEXEC or not. my reason: third party libraries. Only somebody who thinks exclusively about applications as opposed to runtimes/libraries can say something like that. Library writers don't have the luxury of being able to modify any global state. This has all been discussed here before. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHPd8b2ijCOnn/RHQRAuPPAKCm5mcOl8dycDenxi7BNFdrf2IfWgCgmaXQ Fj7V13HU1vX6fM9bRumxRpk= =UIi1 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
you know... i understand the need for FD_CLOEXEC -- in fact i tried petitioning for CLOEXEC options to all the fd creating syscalls something like 7 years ago when i was banging my head against the wall trying to figure out how to thread apache... but even still i'm not convinced that extending every system call which creates an fd is the way to do this. honestly i think there should be a per-task flag which indicates whether fds are by default F_CLOEXEC or not. my reason: third party libraries. i can control all my own code in a threaded program, but i can't control all the code which is linked in. fds are going to leak. if i set a per task flag then the only thing which would break are third party libraries which use fork/exec and aren't aware they may need to unset F_CLOEXEC. personally i'd rather break that than leak fds to another program. but hey i'm happy to see this sort of thing is finally being fixed, thanks. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
On Fri, 16 Nov 2007, Ulrich Drepper wrote: dean gaudet wrote: honestly i think there should be a per-task flag which indicates whether fds are by default F_CLOEXEC or not. my reason: third party libraries. Only somebody who thinks exclusively about applications as opposed to runtimes/libraries can say something like that. Library writers don't have the luxury of being able to modify any global state. This has all been discussed here before. only someone who thinks about writing libraries can say something like that. you've solved the problem for yourself, and for well written applications, but not for the other 99.% of libraries out there. i'm not suggesting the library set the global flag. i'm suggesting that me as an app writer will do so. it seems like both methods are useful. -dean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
you know... i understand the need for FD_CLOEXEC -- in fact i tried petitioning for CLOEXEC options to all the fd creating syscalls something like 7 years ago when i was banging my head against the wall trying to figure out how to thread apache... but even still i'm not convinced that extending every system call which creates an fd is the way to do this. honestly i think there should be a per-task flag which indicates whether fds are by default F_CLOEXEC or not. my reason: third party libraries. i can control all my own code in a threaded program, but i can't control all the code which is linked in. fds are going to leak. if i set a per task flag then the only thing which would break are third party libraries which use fork/exec and aren't aware they may need to unset F_CLOEXEC. personally i'd rather break that than leak fds to another program. but hey i'm happy to see this sort of thing is finally being fixed, thanks. -dean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dean gaudet wrote: honestly i think there should be a per-task flag which indicates whether fds are by default F_CLOEXEC or not. my reason: third party libraries. Only somebody who thinks exclusively about applications as opposed to runtimes/libraries can say something like that. Library writers don't have the luxury of being able to modify any global state. This has all been discussed here before. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHPd8b2ijCOnn/RHQRAuPPAKCm5mcOl8dycDenxi7BNFdrf2IfWgCgmaXQ Fj7V13HU1vX6fM9bRumxRpk= =UIi1 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dean gaudet wrote: i'm not suggesting the library set the global flag. i'm suggesting that me as an app writer will do so. it seems like both methods are useful. No, the global flag is hardly ever useful. You almost never know the details of all the libraries you link to well enough to determine that they don't need FD_CLOEXEC disabled. Even more problematic, you cannot know whether they will need it in future. For applications the solution is simple: wrap to appropriate calls. Apache has all these apr_ wrappers. But them to some good news after all. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHPeim2ijCOnn/RHQRAu8xAJsF/0Ir1PWMbHkVRaI5vKOGFS4tMACfVEs9 pMYAiCAU1E2B+7QR0EP+/F8= =btt9 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
Ulrich Drepper a écrit : This is a first user of sys_indirect. Several of the socket-related system calls which produce a file handle now can be passed an additional parameter to set the FD_CLOEXEC flag. - retval = sock_map_fd(sock); + retval = sock_map_fd_flags(sock, current->indirect_params.file_flags.flags); Yes, we know now why you wanted sys_indirect so much :) However, there should be a macro or something to ease reader mind... #define INDPARAM(SUBSYSNAME,PARAMNAME) \ (current->indirect_params.##SUBSYSNAME.##PARAMNAME) > + retval = sock_map_fd_flags(sock, INDPARAM(file_flags,flags)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
Ulrich Drepper a écrit : This is a first user of sys_indirect. Several of the socket-related system calls which produce a file handle now can be passed an additional parameter to set the FD_CLOEXEC flag. - retval = sock_map_fd(sock); + retval = sock_map_fd_flags(sock, current-indirect_params.file_flags.flags); Yes, we know now why you wanted sys_indirect so much :) However, there should be a macro or something to ease reader mind... #define INDPARAM(SUBSYSNAME,PARAMNAME) \ (current-indirect_params.##SUBSYSNAME.##PARAMNAME) + retval = sock_map_fd_flags(sock, INDPARAM(file_flags,flags)); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
