Re: [patch 7/8] fdmap v2 - implement sys_socket2

[Kyle Moffett <mrmacman_g4@mac.com>]

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/