Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [patch 7/8] fdmap v2 - implement sys_socket2 | Date | Thu, 7 Jun 2007 07:59:47 -0400 |
| |
On Jun 07, 2007, at 06:04:32, Alan Cox wrote: >> continuous allocation are part of the API. It's required by POSIX >> and provided by Unix since the early days. There are entire code >> bases out there which depend on this assumption. Linking with >> code like this, before or after the new version controlled symbol >> is introduced, will break it. > > If your linker is doing its job then you won't be able to link them > together because they have incompatible assumptions. Not exactly > rocket science even if it is done a little differently to the usual > symbol compatibility tests.
No, there is a fundamental problem with "solving" this via linking. Many programs need the continuous FD allocation space, but then have tendancies to do things like:
int i; for (i = 0; i < 1024; i++) if (i != comm_sock && i != server_sock) close(i);
Yes I have seen many such programs, it seems to be a pretty standard idiom.
On the other hand, that makes it completely impossible for libraries to reliably use FDs behind the application's back; they might get closed on you at any time without warning. One such library is glibc; it would really like to be able to use file-descriptors behind the back of the rest of userspace to implement certain functionality: http://www.mail-archive.com/linux-kernel@vger.kernel.org/ msg163522.html
Likewise there are a massive group of other libraries (especially user-interface and server related ones) that would really like to have support for creating file-descriptors without the top-level application closing them randomly (like several shells seem to).
Cheers, Kyle Moffett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |