[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4663A180.8050506@redhat.com>
Date: Sun, 03 Jun 2007 22:22:08 -0700
From: Ulrich Drepper <drepper@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Davide Libenzi <davidel@...ilserver.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 2/2] ufd v1 - use unsequential O(1) fdmap
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
> I actually think that a new system call is _hugely_ messy. It means that
> anybody who wants to use a new feature needs to have a new glibc.
Strange definition of "messy". Have you looked at the proposed dup2
extension? Magic value, semantics which don't match what the function
does today. That's messy.
The private descriptors are something new, programs have to be adjusted.
The open() extension will allow them to be used naturally without
additional interfaces. This leaves converting normal descriptors into
private ones. If the new syscall isn't yet available it's easy enough
to use the syscall() function. The parameters are simple integer so no
tricks needed.
I don't think the requirement for a new glibc should cloud the judgement
when it comes to cleanliness of the API. The new syscall wins there
clearly, I hope you agree. Even the dup2() approach requires program to
either be compiled with headers which have the definitions (i.e., a new
glibc) or programs have to carry their own definitions of the magic
constants and O_NONSEQ. I really cannot see any advantage of
misappropriating dup2.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGY6GA2ijCOnn/RHQRAtQ1AJ4+dDIgeBKlggt4U+lyZnDfQJZ/VQCfRbG4
0FtGWqlLOWFlspMJ9S3xQ7E=
=jrG1
-----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