From: Josh Triplett <josh@joshtriplett.org>
To: kbuild-all@lists.01.org
Subject: Re: [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall
Date: Wed, 25 Dec 2019 02:03:52 -0800 [thread overview]
Message-ID: <20191225100352.GB22699@localhost> (raw)
In-Reply-To: <20191206023346.tubqtdmdbi4truix@yavin.dot.cyphar.com>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On Fri, Dec 06, 2019 at 01:33:46PM +1100, Aleksa Sarai wrote:
> On 2019-11-12, Josh Triplett <josh@joshtriplett.org> wrote:
> > It would be nice if (for instance) it was possible to compile out the
> > old openat and *only* support openat2, or otherwise compile out unused
> > syscalls. In general, we're watching for new code that can't be built
> > out of the kernel even in "allnoconfig"/"tinyconfig".
>
> Based on discussions with the glibc folks, it appears it's not longer
> their policy to emulate syscalls in userspace due to all of the
> headaches associated with it.
>
> So while you could (with some work) emulate openat(2) with openat2(2), I
> don't think there's a clear path to making openat(2) optional -- much
> like open(2) didn't become optional after openat(2).
Not all embedded systems run glibc. If your userspace consists of a
single application or a small set of applications, or you compile
everything against a known set of libraryies that make all the syscalls,
you can know that either everything uses the new syscall or everything
uses the old syscall, and compile out the one you don't use.
prev parent reply other threads:[~2019-12-25 10:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 14:15 [lkp] [+573 bytes kernel size regression] [i386-tinyconfig] [00f2dfd8c2] open: introduce openat2(2) syscall kbuild test robot
2019-11-05 14:44 ` Aleksa Sarai
2019-11-12 22:02 ` Josh Triplett
2019-12-06 2:33 ` Aleksa Sarai
2019-12-25 10:03 ` Josh Triplett [this message]
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=20191225100352.GB22699@localhost \
--to=josh@joshtriplett.org \
--cc=kbuild-all@lists.01.org \
/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: link
Be 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.