All of lore.kernel.org
 help / color / mirror / Atom feed
From: xuyang <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/getcpu: Add libc sched_getcpu() detection && fix compiler errors
Date: Mon, 15 Apr 2019 13:39:15 +0800	[thread overview]
Message-ID: <5CB41903.5010203@cn.fujitsu.com> (raw)
In-Reply-To: <20190412114632.GD28648@haruka.lan>

On 2019/4/12 19:46, Cyril Hrubis wrote:

> Hi!
>>>> -#if defined(__i386__)
>>>> -	return syscall(__NR_getcpu, cpu_id, node_id, cache_struct);
>>>> +#ifndef HAVE_SCHED_GETCPU
>>>> +	return tst_syscall(__NR_getcpu, cpu_id, node_id, cache_struct);
>>>>    #else
>>>>    	*cpu_id = sched_getcpu();
>>>>    #endif
>>> So when __NR_getcpu is not implemented we end up with tst_brk(TCONF,
>>> ...) called from the tst_syscall, right? Since AFAIK the getcpu syscall
>>> is not implemented on all architectures...
>> Yes. It will report TCONF if __NR_getcpu is not implemented.
>>
>>   From getcpu manpage, it is not implemented on all architectures as you
>> said, I think we can remove sched_getcpu and use __NR_getcpu directly.
> Reading the manual pages I think it's correct to fall back to
> sched_getcpu() since as far as I can tell platforms that don't support
> getcpu syscall have implemented the functionality as vDSO. So unless we
> implement vDSO variant of getcpu we have to rely on sched_getcpu().
>
Hi cyril

    Reading the sched_getcpu manpage,I mistakenly think the sched_getcpu uses
    the getcpu syscall diretly.|  |Actually|sched_getcpu uses VDSO getcpu() syscall
    since glibc 2.22. Thanks for you explanation.|



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20190415/5499b512/attachment.html>

  reply	other threads:[~2019-04-15  5:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12  7:03 [LTP] [PATCH] syscalls/getcpu: Add libc sched_getcpu() detection && fix compiler errors Yang Xu
2019-04-12  9:43 ` Cyril Hrubis
2019-04-12 10:46   ` xuyang
2019-04-12 11:46     ` Cyril Hrubis
2019-04-15  5:39       ` xuyang [this message]
2019-04-17  6:05       ` [LTP] [PATCH v2 1/2] syscalls/sched_getaffinity: Cleanup && Convert to new API Yang Xu
2019-04-17  6:05         ` [LTP] [PATCH v2 2/2] syscalls/getcpu:Add libc sched_getcpu() detection &&fix compiler errors Yang Xu
2019-05-13  7:54           ` xuyang
2019-05-13  8:27           ` Petr Vorel
2019-05-13  8:55             ` Cyril Hrubis
2019-05-13  9:40               ` Petr Vorel
2019-04-18 15:27         ` [LTP] [PATCH v2 1/2] syscalls/sched_getaffinity: Cleanup && Convert to new API Cyril Hrubis

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=5CB41903.5010203@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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.