From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: Willy Tarreau <w@1wt.eu>, "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.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:40:44 +0100 [thread overview] Message-ID: <87o9avx5g3.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <CAKOZuesi79-4J8bXU2bTY4876DOtL0K4A_Sr=6XsDD8dESPQbw@mail.gmail.com> (Daniel Colascione's message of "Sun, 11 Nov 2018 00:25:03 -0800") * Daniel Colascione: > On Sun, Nov 11, 2018 at 12:17 AM, Willy Tarreau <w@1wt.eu> wrote: >> >> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> > [1] https://sourceware.org/ >> >> >> Bah, after all, this >> >> wipes quite a bit of the shame I feel every time I do something to >> >> bypass it :-/ >> >> >> The sad thing is that the energy wasted arguing in the bug above could >> >> have been better spent designing and implementing a generic solution >> >> to expose syscalls without depending on glibc's politics anymore. >> >> >> Willy >> >> 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 > > Yes. I'm really not sure what glibc's current policies are meant to > accomplish. They don't serve any useful purpose. There seems to be > this weird subtext that glibc has leverage to change OS design, and it > really doesn't. It's a misplaced idealism and ends up just hurting > everyone. I'm not sure what this comment tries to accomplish. glibc tries to serve many masters: Current and past Linux kernel interfaces, current Hurd kernel interfaces, different versions of POSIX and C (and even C++), current C/C++ programming practice, historic C programming practice, current and historic Linux userspace programming, various platform ABIs, just to name a few. These requirements are often in conflict. >> 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. > > That's a separate point. Yes, gettid should have a wrapper, but *also* > we should have an FD-based interface to processes, because outside > specialized contexts (e.g., parent-child waiting), the traditional > Unix process API really is impossible to use safely. But that's a > separate ongoing discussion. A descriptor-based API would not help glibc that much because there is an expectation encoded into many C programs that the C library does not keep permanently open descriptors for its own internal use. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: Willy Tarreau <w@1wt.eu>, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.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:40:44 +0100 [thread overview] Message-ID: <87o9avx5g3.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <CAKOZuesi79-4J8bXU2bTY4876DOtL0K4A_Sr=6XsDD8dESPQbw@mail.gmail.com> (Daniel Colascione's message of "Sun, 11 Nov 2018 00:25:03 -0800") * Daniel Colascione: > On Sun, Nov 11, 2018 at 12:17 AM, Willy Tarreau <w@1wt.eu> wrote: >> >> On Sun, Nov 11, 2018 at 07:55:30AM +0100, Michael Kerrisk (man-pages) wrote: >> > [1] https://sourceware.org/ >> >> >> Bah, after all, this >> >> wipes quite a bit of the shame I feel every time I do something to >> >> bypass it :-/ >> >> >> The sad thing is that the energy wasted arguing in the bug above could >> >> have been better spent designing and implementing a generic solution >> >> to expose syscalls without depending on glibc's politics anymore. >> >> >> Willy >> >> 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 > > Yes. I'm really not sure what glibc's current policies are meant to > accomplish. They don't serve any useful purpose. There seems to be > this weird subtext that glibc has leverage to change OS design, and it > really doesn't. It's a misplaced idealism and ends up just hurting > everyone. I'm not sure what this comment tries to accomplish. glibc tries to serve many masters: Current and past Linux kernel interfaces, current Hurd kernel interfaces, different versions of POSIX and C (and even C++), current C/C++ programming practice, historic C programming practice, current and historic Linux userspace programming, various platform ABIs, just to name a few. These requirements are often in conflict. >> 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. > > That's a separate point. Yes, gettid should have a wrapper, but *also* > we should have an FD-based interface to processes, because outside > specialized contexts (e.g., parent-child waiting), the traditional > Unix process API really is impossible to use safely. But that's a > separate ongoing discussion. A descriptor-based API would not help glibc that much because there is an expectation encoded into many C programs that the C library does not keep permanently open descriptors for its own internal use. Thanks, Florian
next prev parent reply other threads:[~2018-11-11 10:40 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 [this message] 2018-11-11 10:40 ` Florian Weimer 2018-11-11 10:30 ` Florian Weimer 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=87o9avx5g3.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.