All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li, Aubrey" <aubrey.li@linux.intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Andi Kleen <ak@linux.intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	aubrey.li@intel.com, Linux API <linux-api@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output
Date: Wed, 10 Apr 2019 10:20:28 +0800	[thread overview]
Message-ID: <89957461-ec42-f041-a7e9-2452b2e83d39@linux.intel.com> (raw)
In-Reply-To: <CALCETrWV9SVDGQmzvZuub4aOPGyVqx7gPdk6D0s2_7j471jT_g@mail.gmail.com>

On 2019/4/10 9:58, Andy Lutomirski wrote:
> On Tue, Apr 9, 2019 at 6:55 PM Aubrey Li <aubrey.li@linux.intel.com> wrote:
>>
>> The architecture specific information of the running processes could
>> be useful to the userland. Add support to examine process architecture
>> specific information externally.
>>
>> Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Andi Kleen <ak@linux.intel.com>
>> Cc: Tim Chen <tim.c.chen@linux.intel.com>
>> Cc: Dave Hansen <dave.hansen@intel.com>
>> Cc: Arjan van de Ven <arjan@linux.intel.com>
>> Cc: Linux API <linux-api@vger.kernel.org>
>> Cc: Alexey Dobriyan <adobriyan@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> ---
>>  fs/proc/array.c         | 5 +++++
>>  include/linux/proc_fs.h | 2 ++
>>  2 files changed, 7 insertions(+)
>>
>> diff --git a/fs/proc/array.c b/fs/proc/array.c
>> index 2edbb657f859..331592a61718 100644
>> --- a/fs/proc/array.c
>> +++ b/fs/proc/array.c
>> @@ -401,6 +401,10 @@ static inline void task_thp_status(struct seq_file *m, struct mm_struct *mm)
>>         seq_printf(m, "THP_enabled:\t%d\n", thp_enabled);
>>  }
>>
>> +void __weak arch_proc_pid_status(struct seq_file *m, struct task_struct *task)
>> +{
>> +}
> 
> This pointlessly bloats other architectures.  Do this instead in an
> appropriate header:
> 
> #ifndef arch_proc_pid_status
> static inline void arch_proc_pid_status(...)
> {
> }
> #endif
> 

I saw a bunch of similar weak functions, is it not acceptable?

fs/proc$ grep weak *.c
cpuinfo.c:__weak void arch_freq_prepare_all(void)
meminfo.c:void __attribute__((weak)) arch_report_meminfo(struct seq_file *m)
vmcore.c:int __weak elfcorehdr_alloc(unsigned long long *addr, unsigned long long *size)
vmcore.c:void __weak elfcorehdr_free(unsigned long long addr)
vmcore.c:ssize_t __weak elfcorehdr_read(char *buf, size_t count, u64 *ppos)
vmcore.c:ssize_t __weak elfcorehdr_read_notes(char *buf, size_t count, u64 *ppos)
vmcore.c:int __weak remap_oldmem_pfn_range(struct vm_area_struct *vma,
vmcore.c:ssize_t __weak

> Or add /proc/PID/x86_status, which sounds better in most respects to me.
> 

I didn't figure out how to make /proc/PID/x86_status invisible to other
architectures in an appropriate way, do you have any suggestions?

Thanks,
-Aubrey

  reply	other threads:[~2019-04-10  2:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10  1:53 [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output Aubrey Li
2019-04-10  1:53 ` [PATCH v14 2/3] x86,/proc/pid/status: Add AVX-512 usage elapsed time Aubrey Li
2019-04-10  1:53 ` [PATCH v14 3/3] Documentation/filesystems/proc.txt: add AVX512_elapsed_ms Aubrey Li
2019-04-10  1:58 ` [PATCH v14 1/3] /proc/pid/status: Add support for architecture specific output Andy Lutomirski
2019-04-10  2:20   ` Li, Aubrey [this message]
2019-04-10  2:25     ` Andy Lutomirski
2019-04-10  2:36       ` Li, Aubrey
2019-04-10  3:39         ` Li, Aubrey
2019-04-10 14:54           ` Andy Lutomirski
2019-04-11  1:02             ` Li, Aubrey
2019-04-12  0:55               ` Li, Aubrey

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=89957461-ec42-f041-a7e9-2452b2e83d39@linux.intel.com \
    --to=aubrey.li@linux.intel.com \
    --cc=adobriyan@gmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --cc=aubrey.li@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    /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.