Re: Syslets, Threadlets, generic AIO support, v6

[Eric Dumazet <dada1@cosmosbay.com>]

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/