From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: Zack Weinberg <zackw@panix.com>, "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>, Linux Kernel Mailing List <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>, GNU C Library <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Mon, 12 Nov 2018 20:11:17 +0100 [thread overview] Message-ID: <87lg5ym7qi.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <CAKOZuev7zqq+xpjyDA2mSdy-zwyNjECCzLsBELF6_v1rwar_mA@mail.gmail.com> (Daniel Colascione's message of "Mon, 12 Nov 2018 10:28:56 -0800") * Daniel Colascione: > What about off_t differences? Again, it doesn't matter. From the > *kernel's* point of view, there's one width of offset parameter per > system call per architecture. The library I'm proposing would expose > this parameter literally. Does this mean the application author needs to know when to split an off_t argument into two, and when to pass it as a single argument, and when to insert dummy arguments for alignment, depending on the architecture? >> And that means you wouldn't get as much >> decoupling from the C and POSIX standards -- both of which specify at >> least part of those semantics -- as you want, and we would still be >> having these arguments. For example, it would be every bit as >> troublesome for liblinuxabi.so.1 to export set_robust_list as it would >> be for libc.so.6 to do that. > > Why? Such an exported function would cause no trouble until called, > and there are legitimate reasons for calling such a function. Not > everyone, as mentioned, wants to write a program that relies on libc. For that use case, a machine-readable system call ABI specification is the only reasonable approach: Some people want inline system calls, others want dedicated routines per system call. The calling convention for the dedicated functions will vary, and the way errors are handled as well. Some want connect calls to be handled by socketcall if possible, others prefer the direct call. The nice thing here is that once you settled for a particular approach, the functions are really small and will not change, so there is no real need for dynamic linking. The challenge here is to come up with a uniform description of the system call interface for all architectures, and for application programmer's sanity, make sure that the kernel adds generic system calls in a single version, across all architectures. > This stance in the paragraph I've quoted is another example of glibc's > misplaced idealism. As I've elaborated elsewhere, people use signals > for many purposes today. The current signals API is extremely > difficult to use correctly in a process in which multiple unrelated > components want to take advantage of signal-handling functionality. > Users deserve a cleaner, modern, and safe API. It's not productive > withhold improvements to the signal API and gate them on unrelated > features like process handles merely because, in the personal > judgement of the glibc maintainers, developers should use signals for > fewer things. The two aren't unrelated. If you take asynchronous signals out of the picture, the design becomes simpler and easier to use. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Daniel Colascione <dancol@google.com> Cc: Zack Weinberg <zackw@panix.com>, "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>, Linux Kernel Mailing List <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>, GNU C Library <libc-alpha@sourceware.org> Subject: Re: Official Linux system wrapper library? Date: Mon, 12 Nov 2018 20:11:17 +0100 [thread overview] Message-ID: <87lg5ym7qi.fsf@oldenburg.str.redhat.com> (raw) In-Reply-To: <CAKOZuev7zqq+xpjyDA2mSdy-zwyNjECCzLsBELF6_v1rwar_mA@mail.gmail.com> (Daniel Colascione's message of "Mon, 12 Nov 2018 10:28:56 -0800") * Daniel Colascione: > What about off_t differences? Again, it doesn't matter. From the > *kernel's* point of view, there's one width of offset parameter per > system call per architecture. The library I'm proposing would expose > this parameter literally. Does this mean the application author needs to know when to split an off_t argument into two, and when to pass it as a single argument, and when to insert dummy arguments for alignment, depending on the architecture? >> And that means you wouldn't get as much >> decoupling from the C and POSIX standards -- both of which specify at >> least part of those semantics -- as you want, and we would still be >> having these arguments. For example, it would be every bit as >> troublesome for liblinuxabi.so.1 to export set_robust_list as it would >> be for libc.so.6 to do that. > > Why? Such an exported function would cause no trouble until called, > and there are legitimate reasons for calling such a function. Not > everyone, as mentioned, wants to write a program that relies on libc. For that use case, a machine-readable system call ABI specification is the only reasonable approach: Some people want inline system calls, others want dedicated routines per system call. The calling convention for the dedicated functions will vary, and the way errors are handled as well. Some want connect calls to be handled by socketcall if possible, others prefer the direct call. The nice thing here is that once you settled for a particular approach, the functions are really small and will not change, so there is no real need for dynamic linking. The challenge here is to come up with a uniform description of the system call interface for all architectures, and for application programmer's sanity, make sure that the kernel adds generic system calls in a single version, across all architectures. > This stance in the paragraph I've quoted is another example of glibc's > misplaced idealism. As I've elaborated elsewhere, people use signals > for many purposes today. The current signals API is extremely > difficult to use correctly in a process in which multiple unrelated > components want to take advantage of signal-handling functionality. > Users deserve a cleaner, modern, and safe API. It's not productive > withhold improvements to the signal API and gate them on unrelated > features like process handles merely because, in the personal > judgement of the glibc maintainers, developers should use signals for > fewer things. The two aren't unrelated. If you take asynchronous signals out of the picture, the design becomes simpler and easier to use. Thanks, Florian
next prev parent reply other threads:[~2018-11-12 19:11 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 [this message] 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=87lg5ym7qi.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 \ --cc=zackw@panix.com \ /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.