Messages in this thread | | | Date | Wed, 30 May 2007 13:21:11 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: Syslets, Threadlets, generic AIO support, v6 |
| |
On Wed, 30 May 2007, Linus Torvalds wrote:
> On Wed, 30 May 2007, Davide Libenzi wrote: > > > > Here I think we are forgetting that glibc is userspace and there's no > > separation between the application code and glibc code. An application > > linking to glibc can break glibc in thousand ways, indipendently from fds > > or not fds. Like complaining that glibc is broken because printf() > > suddendly does not work anymore ;) > > No, Davide, the problem is that some applications depend on getting > _specific_ file descriptors. > > For example, if you do > > close(0); > .. something else .. > if (open("myfile", O_RDONLY) < 0) > exit(1); > > you can (and should) depend on the open returning zero. > > So library routines *must not* open file descriptors in the normal space. > > (The same is true of real applications doing the equivalent of > > for (i = 0; i < NR_OPEN; i++) > close(i); > > to clean up all file descriptors before doing something new. And yes, I > think it was bash that used to *literally* do something like that a long > time ago.
Right. I misunderstood Uli and Ingo. I thought it was like trying to protect glibc from intentional application mis-behaviour.
> Another example of the same thing: people open file descriptors and know > that they'll be "dense" in the result, and then use "select()" on them. > > So it's true that file descriptors can't be used randomly by the standard > libraries - they'd need to have some kind of separate "private space". > > Which *could* be something as simple as saying "bit 30 in the file > descriptor specifies a separate fd space" along with some flags to make > open and friends return those separate fd's. That makes them useless for > "select()" (which assumes a flat address space, of course), but would be > useful for just about anything else.
I think it can be solved in a few ways. Yours or Ingo's (or something else) can work, to solve the above "legacy" fd space expectations.
- Davide
- 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/
| |