[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <9a83ea72-7651-477e-b553-43ae12926ef6@www.fastmail.com>
Date: Thu, 27 May 2021 12:35:58 -0700
From: "Andy Lutomirski" <luto@...nel.org>
To: "Len Brown" <lenb@...nel.org>, "Borislav Petkov" <bp@...en8.de>
Cc: "Bae, Chang Seok" <chang.seok.bae@...el.com>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...nel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
"Dave Hansen" <dave.hansen@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: second, sync-alloc syscall
On Thu, May 27, 2021, at 6:59 AM, Len Brown wrote:
> On Thu, May 27, 2021 at 7:14 AM Borislav Petkov <bp@...en8.de> wrote:
>
> > So if this second syscall doesn't sound really great, I'd say we stick
> > to the #NM-based allocation and keep this one in the bag for now and
> > take it out only if it turns out that it makes sense as a use case.
>
> I agree. Simple to add if later, if something requires it --
> though given it's modest incremental value, currently hard to justify.
>
> > As tglx said: it is easy to add stuff later. It is a lot harder - even
> > impossible - to remove already present machinery.
Also, in case you haven’t been watching the other thread, this whole thing needs to wait until the existing code gets cleaned up. The current signal code is a disaster.
>
> Indeed.
>
> thanks!
> Len Brown, Intel Open Source Technology Center
>
Powered by blists - more mailing lists