[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <465DD6C3.6080102@redhat.com>
Date: Wed, 30 May 2007 12:55:47 -0700
From: Ulrich Drepper <drepper@...hat.com>
To: Davide Libenzi <davidel@...ilserver.org>
CC: Ingo Molnar <mingo@...e.hu>, Jeff Garzik <jeff@...zik.org>,
Zach Brown <zach.brown@...cle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@....com.au>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Evgeniy Polyakov <johnpol@....mipt.ru>,
"David S. Miller" <davem@...emloft.net>,
Suparna Bhattacharya <suparna@...ibm.com>,
Jens Axboe <jens.axboe@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Davide Libenzi wrote:
> An application
> linking to glibc can break glibc in thousand ways, indipendently from fds
> or not fds.
It's not (only/mainly) about breaking. File descriptors are a resources
which has to be used under the control of the program. The runtime
cannot just steal some for itself. This indirectly leads to breaking
code. We've seen this many times and I keep repeating the same issue
over and over again: why do we have MAP_ANON instead of keeping a file
descriptor with /dev/null open? Why is mmap made more complicated by
allowing the file descriptor to be closed after the mmap() call is done?
Take a look at a process running your favorite shell. Ever wonder why
there is this stray file descriptor with a high number?
$ cat /proc/3754/cmdline
bash
$ ll /proc/3754/fd/
total 0
lrwx------ 1 drepper drepper 64 2007-05-30 12:50 0 -> /dev/pts/19
lrwx------ 1 drepper drepper 64 2007-05-30 12:50 1 -> /dev/pts/19
lrwx------ 1 drepper drepper 64 2007-05-30 12:49 2 -> /dev/pts/19
lrwx------ 1 drepper drepper 64 2007-05-30 12:50 255 -> /dev/pts/19
File descriptors must be requested explicitly and cannot be implicitly
consumed.
All that and the other problem I mentioned earlier today about auxiliary
data. File descriptors are not the ideal interface. Elegant: yes,
ideal: no. Fro physics and math you might have learned that not every
result that looks clean and beautiful is correct.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGXdbC2ijCOnn/RHQRAgBbAJ0RoNsQr4L6Bm5hLy7somAKeTqCcQCbBHmx
8hzG+1w0rYMTqXxNmi/QQ7o=
=O7Xm
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists