Messages in this thread | | | Date | Wed, 30 May 2007 23:53:54 +0200 | From | Eric Dumazet <> | Subject | Re: Syslets, Threadlets, generic AIO support, v6 |
| |
Linus Torvalds a écrit : > > On Wed, 30 May 2007, Eric Dumazet wrote: >>> No, Davide, the problem is that some applications depend on getting >>> _specific_ file descriptors. >> Fix the application, and not adding kernel bloat ? > > No. The application is _correct_. It's how file descriptors are defined to > work. > >> Then you can also exclude multi-threading, since a thread (even not inside >> glibc) can also use socket()/pipe()/open()/whatever and take the zero file >> descriptor as well. > > Totally different. That's an application internal issue. It does *not* > mean that we can break existing standards. > >> The only hardcoded thing in Unix is 0, 1 and 2 fds. > > Wrong. I already gave an example of real code that just didn't bother to > keep track of which fd's it had open, and closed them all. Partly, in > fact, because you can't even _know_ which fd's you have open when somebody > else just execve's you.
If someone really cares, /proc/self/fd can help. But one shouldn't care at all.
About the things that the process can do before execing() a process, file descriptors outside of 0,1,2 are the most obvious thing, but you also have alarm(), or stupid rlimits.
> > You can call it buggy, but the fact is, if you do, you're SIMPLY WRONG. > > You cannot just change years and years of coding practice, and standard > documentations. The behaviour of file descriptors is a fact. Ignoring that > fact because you don't like it is naïve and simply not realistic.
I want to change nothing. Current situation is fine and well documented, thank you.
If a program does "for (i = 0; i < NR_OPEN; i++) close(i);", this *will*/*should* work as intended : close all files descriptors from 0 to NR_OPEN. Big deal.
But you wont find in a program :
FILE *fp = fopen("somefile", "r"); for (i = 0; i < NR_OPEN; i++) close(i); while (fgets(buff, sizeof(buff), fp)) { }
You and/or others want to add fd namespaces and other hacks.
I saw on this thread suspicious examples, I am waiting for a real one, justifying all this stuff.
After file descriptors separation, I guess we'll need memory space separation as well, signal separations (SIGALRM comes to mind), uid/gid separation, cpu time separation, and so on... setrlimit() layered for every shared lib.
- 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/
| |