From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: "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>, Willy Tarreau <w@1wt.eu>, 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: Fri, 23 Nov 2018 14:34:26 +0100 [thread overview] Message-ID: <87efbbvrx9.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: CAKOZuetdgk1QYhx1538-98rFpogMin=8DkPnCtU9_=ip23Vk7w@mail.gmail.com * Daniel Colascione: > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer <fweimer@redhat.com> wrote: >> * Daniel Colascione: >> >>> If the kernel provides a system call, libc should provide a C wrapper >>> for it, even if in the opinion of the libc maintainers, that system >>> call is flawed. >> >> It's not that simple, I think. What about bdflush? socketcall? >> getxpid? osf_gettimeofday? set_robust_list? > > What about them? Mentioning that these system calls exist is not in > itself an argument. But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. >> There are quite a few irregularities > > So? I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. >> and some editorial discretion appears to be unavoidable. > > That's an assertion, not an argument, and I strongly disagree. *Why* > do you think "editorial discretion" is unavoidable? We do not want application authors to write code which uses socketcall, however it is the right system call for the BSD sockets API if you need compatibility back to Linux 2.6.32 and before. If we application authors seitched to socketall, applications would not be portable (at the source level) to new architectures which do not have socketcall. We do not want to force application authors to call osf_gettimeofday instead of gettimeofday on Alpha. We do not want to encourage library authors to call set_robust_list because doing so would break robust mutex support in any libc. >> Even if we were to provide perfectly consistent system call wrappers >> under separate names, we'd still expose different calling conventions >> for things like off_t to applications, which would make using some of >> the system calls quite difficult and surprisingly non-portable. > > We can learn something from how Windows does things. On that system, > what we think of as "libc" is actually two parts. (More, actually, but > I'm simplifying.) At the lowest level, you have the semi-documented > ntdll.dll, which contains raw system call wrappers and arcane > kernel-userland glue. On top of ntdll live the "real" libc > (msvcrt.dll, kernel32.dll, etc.) that provide conventional > application-level glue. The tight integration between ntdll.dll and > the kernel allows Windows to do very impressive things. > We should adopt a similar approach. Most kernel developers claim that a stable userspace ABI is desirable. With your proposal, we need to maintain three stable ABI layers instead of two, without actually adding any functionality. That doesn't seem to be a good way of using developer resources. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: "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>, Willy Tarreau <w@1wt.eu>, 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: Fri, 23 Nov 2018 14:34:26 +0100 [thread overview] Message-ID: <87efbbvrx9.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: CAKOZuetdgk1QYhx1538-98rFpogMin=8DkPnCtU9_=ip23Vk7w@mail.gmail.com * Daniel Colascione: > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer <fweimer@redhat.com> wrote: >> * Daniel Colascione: >> >>> If the kernel provides a system call, libc should provide a C wrapper >>> for it, even if in the opinion of the libc maintainers, that system >>> call is flawed. >> >> It's not that simple, I think. What about bdflush? socketcall? >> getxpid? osf_gettimeofday? set_robust_list? > > What about them? Mentioning that these system calls exist is not in > itself an argument. But socketcall does not exist on all architectures. Neither does getpid, it's called getxpid on some architectures. >> There are quite a few irregularities > > So? I think it would be a poor approach to expose application developers to these portability issues. We need to abstract over these differences at a certain layer, and applications are too late. >> and some editorial discretion appears to be unavoidable. > > That's an assertion, not an argument, and I strongly disagree. *Why* > do you think "editorial discretion" is unavoidable? We do not want application authors to write code which uses socketcall, however it is the right system call for the BSD sockets API if you need compatibility back to Linux 2.6.32 and before. If we application authors seitched to socketall, applications would not be portable (at the source level) to new architectures which do not have socketcall. We do not want to force application authors to call osf_gettimeofday instead of gettimeofday on Alpha. We do not want to encourage library authors to call set_robust_list because doing so would break robust mutex support in any libc. >> Even if we were to provide perfectly consistent system call wrappers >> under separate names, we'd still expose different calling conventions >> for things like off_t to applications, which would make using some of >> the system calls quite difficult and surprisingly non-portable. > > We can learn something from how Windows does things. On that system, > what we think of as "libc" is actually two parts. (More, actually, but > I'm simplifying.) At the lowest level, you have the semi-documented > ntdll.dll, which contains raw system call wrappers and arcane > kernel-userland glue. On top of ntdll live the "real" libc > (msvcrt.dll, kernel32.dll, etc.) that provide conventional > application-level glue. The tight integration between ntdll.dll and > the kernel allows Windows to do very impressive things. > We should adopt a similar approach. Most kernel developers claim that a stable userspace ABI is desirable. With your proposal, we need to maintain three stable ABI layers instead of two, without actually adding any functionality. That doesn't seem to be a good way of using developer resources. Thanks, Florian
next prev parent reply other threads:[~2018-11-23 13:34 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 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 [this message] 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=87efbbvrx9.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.