From: "H. Peter Anvin" <hpa@zytor.com>
To: josh@joshtriplett.org, Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
"x86@kernel.org" <x86@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v3 3/3] x86: Support compiling out userspace I/O (iopl and ioperm)
Date: Wed, 29 Oct 2014 10:20:28 -0700 [thread overview]
Message-ID: <545121DC.5050305@zytor.com> (raw)
In-Reply-To: <20141029171754.GA18888@cloud>
On 10/29/2014 10:17 AM, josh@joshtriplett.org wrote:
>>
>> But this is entirely a style decision, so I leave it up to the x86
>> maintainers ...
>
> I can certainly do that if the x86 maintainers prefer, but that tends to
> produce a net increase in lines of code, as well as duplicating all the
> function prototypes, which to me seems more error-prone. If the
> stub versions contained any code, rather than just becoming no-ops, I'd
> definitely do that.
>
I concur with this style choice.
>> Another nit may be that we should call this CONFIG_SYSCALL_IOPL or
>> CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_*
>> naming thread? Again, I don't really care strongly beyond really
>> wanting to use this new feature! :)
>
> I don't feel strongly about the naming. Ingo?
It is sort of a special case here, as this reflects more than one syscall.
-hpa
next prev parent reply other threads:[~2014-10-29 17:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 16:02 [PATCH v3 1/3] x86: process: Unify 32-bit and 64-bit copy_thread I/O bitmap handling Josh Triplett
2014-10-29 16:03 ` [PATCH v3 2/3] x86: tss: Eliminate fragile calculation of TSS segment limit Josh Triplett
2014-10-29 16:03 ` Josh Triplett
2014-10-29 16:10 ` [PATCH v3 3/3] x86: Support compiling out userspace I/O (iopl and ioperm) Josh Triplett
2014-10-29 16:10 ` Josh Triplett
2014-10-29 16:59 ` Kees Cook
2014-10-29 16:59 ` Kees Cook
2014-10-29 17:17 ` josh
2014-10-29 17:17 ` josh
2014-10-29 17:17 ` josh
2014-10-29 17:20 ` H. Peter Anvin
2014-10-29 17:20 ` H. Peter Anvin
2014-10-29 17:20 ` H. Peter Anvin [this message]
2014-10-29 17:58 ` josh
2014-10-29 17:58 ` josh
2014-10-29 17:58 ` josh
2014-10-29 16:59 ` Kees Cook
2014-10-29 21:00 ` Thomas Gleixner
2014-10-29 21:00 ` Thomas Gleixner
2014-11-01 19:41 ` Josh Triplett
2014-11-01 19:41 ` Josh Triplett
2014-11-01 19:41 ` Josh Triplett
2014-10-29 21:00 ` Thomas Gleixner
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=545121DC.5050305@zytor.com \
--to=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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.