[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a9e6bd9-8e1a-9fe5-135d-c7a49697b5a4@metux.net>
Date: Thu, 25 Apr 2019 12:11:57 +0200
From: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To: "Li, Aubrey" <aubrey.li@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>
Cc: mingo@...hat.com, peterz@...radead.org, hpa@...or.com,
ak@...ux.intel.com, tim.c.chen@...ux.intel.com,
dave.hansen@...el.com, arjan@...ux.intel.com, adobriyan@...il.com,
akpm@...ux-foundation.org, aubrey.li@...el.com,
linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v17 1/3] proc: add /proc/<pid>/arch_status
On 25.04.19 03:50, Li, Aubrey wrote:
>>> +>>> +config PROC_PID_ARCH_STATUS>>> + bool "Enable
/proc/<pid>/arch_status file">>>> Why is this switchable? x86 selects it
if PROC_FS is enabled and all other>> architectures are absolutely not
interested in this.> > Above and this, I was trying to avoid an empty
arch_file on other architectures.> In previous proposal the entry only
exists on the platform with AVX512.
Why not making it depend on those archs that actually support it ?
> In that way proc_task_arch_status() should be defined in asm/processor.h,> but proc_task_arch_status() has four parameters, I don't want
unnecessary> "struct pid_namespace *ns" and "struct pid *pid" leaked
into arch headers,> so I defined task_arch_status(m, task) to avoid that.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287
Powered by blists - more mailing lists