[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56C44560.6010708@list.ru>
Date: Wed, 17 Feb 2016 13:03:12 +0300
From: Stas Sergeev <stsp@...t.ru>
To: Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>
Cc: x86@...nel.org, Denys Vlasenko <dvlasenk@...hat.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Pavel Emelyanov <xemul@...allels.com>,
Brian Gerst <brgerst@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v5 1/4] x86/signal/64: Add a comment about sigcontext->fs
and gs
17.02.2016 10:21, Ingo Molnar пишет:
>
> * Andy Lutomirski <luto@...nel.org> wrote:
>
>> + * If the kernel ever adds explicit fs, gs, fsbase, and gsbase
>> + * save/restore, it will most likely need to be opt-in and use
>> + * different context slots.
>
> Btw., that's not necessarily true: it could also be made opt-out, and a
> modify_ldt() or any other cleanly identifiable legacy usage/signature that is
> associated with DOSEMU might trigger the opt-out automatically as well.
But there are the new versions of dosemu that still use
"modify_ldt() or any other cleanly identifiable legacy usage/signature"
and yet wants a new functionality.
Please don't go for such an unreliable heuristic.
> I.e. behaviorally it would still keep the ABI and modern default behavior could
> still be whatever we want to make it.
You can allow glibc to deal with the opt-ins.
It has symbol versioning system AFAIK exactly for that.
Powered by blists - more mailing lists