From: Florian Weimer <fweimer@redhat.com> To: Willy Tarreau <w@1wt.eu> Cc: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>, Daniel Colascione <dancol@google.com>, linux-kernel <linux-kernel@vger.kernel.org>, Joel Fernandes <joelaf@google.com>, Linux API <linux-api@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>, "Carlos O'Donell" <carlos@redhat.com>, "libc-alpha\@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Sun, 11 Nov 2018 11:30:25 +0100 [thread overview] Message-ID: <87y39zx5xa.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <20181111081725.GA30248@1wt.eu> (Willy Tarreau's message of "Sun, 11 Nov 2018 09:17:25 +0100") * Willy Tarreau: > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a >> longstanding example. > > This one was a sad read and shows that applications will continue to > suffer from glibc's prehistorical view on operating systems and will > continue to have to define their own syscall wrappers to exploit the > full potential of the modern operating systems they execute on. What's modern about a 15-bit thread identifier? I understand that using this interface is required in some cases (which includes some system calls for which glibc does provide wrappers), but I assumed that it was at least understood that these reusable IDs for tasks were an extremely poor interface. Aren't the resulting bugs common knowledge? > This reminds me when one had to write their own spinlocks and atomics > many years ago. Seeing comments suggesting an application should open > /proc/$PID makes me really wonder if people actually want to use slow > and insecure applications designed this way. I don't understand. If you want a non-reusable identifier, you have to go through the /proc interface anyway. I think the recommendation is to use the PID/start time combination to get a unique process identifier or something like that. I wanted to add gettid to glibc this cycle, but your comments suggest to me that if we did this, we'd likely never get a proper non-reusable thread identifier from the kernel. So I'm not sure what do anymore. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Willy Tarreau <w@1wt.eu> Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>, Daniel Colascione <dancol@google.com>, linux-kernel <linux-kernel@vger.kernel.org>, Joel Fernandes <joelaf@google.com>, Linux API <linux-api@vger.kernel.org>, Vlastimil Babka <vbabka@suse.cz>, Carlos O'Donell <carlos@redhat.com>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Sun, 11 Nov 2018 11:30:25 +0100 [thread overview] Message-ID: <87y39zx5xa.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <20181111081725.GA30248@1wt.eu> (Willy Tarreau's message of "Sun, 11 Nov 2018 09:17:25 +0100") * Willy Tarreau: > On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=6399 is a >> longstanding example. > > This one was a sad read and shows that applications will continue to > suffer from glibc's prehistorical view on operating systems and will > continue to have to define their own syscall wrappers to exploit the > full potential of the modern operating systems they execute on. What's modern about a 15-bit thread identifier? I understand that using this interface is required in some cases (which includes some system calls for which glibc does provide wrappers), but I assumed that it was at least understood that these reusable IDs for tasks were an extremely poor interface. Aren't the resulting bugs common knowledge? > This reminds me when one had to write their own spinlocks and atomics > many years ago. Seeing comments suggesting an application should open > /proc/$PID makes me really wonder if people actually want to use slow > and insecure applications designed this way. I don't understand. If you want a non-reusable identifier, you have to go through the /proc interface anyway. I think the recommendation is to use the PID/start time combination to get a unique process identifier or something like that. I wanted to add gettid to glibc this cycle, but your comments suggest to me that if we did this, we'd likely never get a proper non-reusable thread identifier from the kernel. So I'm not sure what do anymore. Thanks, Florian
next prev parent reply other threads:[~2018-11-11 10:30 UTC|newest] Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-10 18:52 Official Linux system wrapper library? Daniel Colascione 2018-11-10 19:01 ` Willy Tarreau 2018-11-10 19:06 ` Daniel Colascione 2018-11-10 19:33 ` Willy Tarreau 2018-11-10 19:20 ` Greg KH 2018-11-10 19:58 ` Vlastimil Babka 2018-11-12 2:03 ` Carlos O'Donell 2018-11-12 2:24 ` Carlos O'Donell 2018-11-12 2:36 ` Greg KH 2018-11-12 16:08 ` Jonathan Corbet 2018-11-12 20:03 ` Greg KH 2018-12-09 4:38 ` Randy Dunlap 2018-12-10 16:27 ` Jonathan Corbet 2018-12-10 17:39 ` Carlos O'Donell 2018-12-10 23:32 ` Randy Dunlap 2018-11-12 5:46 ` Andy Lutomirski 2018-11-11 6:55 ` Michael Kerrisk (man-pages) 2018-11-11 8:17 ` Willy Tarreau 2018-11-11 8:25 ` Daniel Colascione 2018-11-11 10:40 ` Florian Weimer 2018-11-11 10:40 ` Florian Weimer 2018-11-11 10:30 ` Florian Weimer [this message] 2018-11-11 10:30 ` Florian Weimer 2018-11-11 11:02 ` Willy Tarreau 2018-11-11 12:07 ` Florian Weimer 2018-11-11 12:07 ` Florian Weimer 2018-11-11 10:53 ` Michael Kerrisk (man-pages) 2018-11-11 11:02 ` Florian Weimer 2018-11-11 11:02 ` Florian Weimer 2018-11-12 16:43 ` Joseph Myers 2018-11-13 15:15 ` Carlos O'Donell 2018-11-11 11:11 ` Willy Tarreau 2018-11-11 11:46 ` Florian Weimer 2018-11-11 11:46 ` Florian Weimer 2018-11-11 12:09 ` Willy Tarreau 2018-11-12 12:25 ` Florian Weimer 2018-11-12 12:25 ` Florian Weimer 2018-11-12 17:36 ` Joseph Myers 2018-11-12 17:53 ` Greg KH 2018-11-12 18:09 ` Joseph Myers 2018-11-12 18:14 ` Randy Dunlap 2018-11-12 16:59 ` Joseph Myers 2018-11-14 12:03 ` Adam Borowski 2018-11-14 12:10 ` Florian Weimer 2018-11-14 12:10 ` Florian Weimer 2018-11-16 21:24 ` Alan Cox 2018-11-11 11:09 ` Florian Weimer 2018-11-11 11:09 ` Florian Weimer 2018-11-11 14:22 ` Daniel Colascione 2018-11-12 1:44 ` Paul Eggert 2018-11-12 8:11 ` Florian Weimer 2018-11-12 8:11 ` Florian Weimer 2018-11-12 13:19 ` Daniel Colascione 2018-11-12 17:24 ` Zack Weinberg 2018-11-12 18:28 ` Daniel Colascione 2018-11-12 19:11 ` Florian Weimer 2018-11-12 19:11 ` Florian Weimer 2018-11-12 19:26 ` Daniel Colascione 2018-11-12 22:51 ` Joseph Myers 2018-11-12 23:10 ` Daniel Colascione 2018-11-12 23:26 ` Joseph Myers 2018-11-12 22:34 ` Joseph Myers 2018-11-13 19:39 ` Dave Martin 2018-11-13 20:58 ` Andy Lutomirski 2018-11-14 10:54 ` Dave Martin 2018-11-14 11:40 ` Florian Weimer 2018-11-14 11:40 ` Florian Weimer 2018-11-15 10:33 ` Dave Martin 2018-11-14 11:58 ` Szabolcs Nagy 2018-11-14 14:46 ` Andy Lutomirski 2018-11-14 15:07 ` Florian Weimer 2018-11-14 15:07 ` Florian Weimer 2018-11-14 17:40 ` Joseph Myers 2018-11-14 18:13 ` Paul Eggert 2018-11-14 14:58 ` Carlos O'Donell 2018-11-14 17:15 ` Arnd Bergmann 2018-11-14 18:30 ` Joseph Myers 2018-11-14 18:30 ` Joseph Myers 2018-11-14 15:40 ` Daniel Colascione 2018-11-14 18:15 ` Joseph Myers 2018-11-14 18:35 ` Daniel Colascione 2018-11-14 18:47 ` Joseph Myers 2018-11-15 5:30 ` Theodore Y. Ts'o 2018-11-15 16:29 ` Joseph Myers 2018-11-15 17:08 ` Theodore Y. Ts'o 2018-11-15 17:14 ` Joseph Myers 2018-11-15 21:00 ` Carlos O'Donell 2018-11-15 20:34 ` Carlos O'Donell 2018-11-23 13:34 ` Florian Weimer 2018-11-23 13:34 ` Florian Weimer 2018-11-23 14:11 ` David Newall 2018-11-23 15:23 ` Szabolcs Nagy 2018-11-24 3:41 ` David Newall 2018-11-28 13:18 ` David Laight 2018-11-23 20:15 ` Daniel Colascione 2018-11-23 23:19 ` Dmitry V. Levin 2018-11-12 12:45 ` Szabolcs Nagy 2018-11-12 14:35 ` Theodore Y. Ts'o 2018-11-12 14:40 ` Daniel Colascione
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87y39zx5xa.fsf@oldenburg.str.redhat.com \ --to=fweimer@redhat.com \ --cc=carlos@redhat.com \ --cc=dancol@google.com \ --cc=joelaf@google.com \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=vbabka@suse.cz \ --cc=w@1wt.eu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.