mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Palmer Dabbelt <palmer@dabbelt.com>,
	rostedt@goodmis.org,  namcao@linutronix.de
Cc: mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	 linux-trace-kernel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rv: Support systems with time64-only syscalls
Date: Tue, 05 Aug 2025 08:18:46 +0200	[thread overview]
Message-ID: <580bf2db57cefa07631e73e5af453228cfb3cecb.camel@redhat.com> (raw)
In-Reply-To: <20250804194518.97620-2-palmer@dabbelt.com>

On Mon, 2025-08-04 at 12:45 -0700, Palmer Dabbelt wrote:
> From: Palmer Dabbelt <palmer@dabbelt.com>
> 
> Some systems (like 32-bit RISC-V) only have the 64-bit time_t
> versions of syscalls.  So handle the 32-bit time_t version of those
> being undefined.
> 
> Fixes: f74f8bb246cf ("rv: Add rtapp_sleep monitor")
> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
> ---
> This seems a little ugly, as it'll blow up when neither is defined. 
> Some #if/#error type stuff seemed uglier, though, and that's the best
> I could come up with.  I figure anyone without either flavor of futex
> call is probably deep enough in the weeds to just figure what blows
> up here...

Yeah, this is getting ugly.. I wasn't fun of this ifdeffery already but
a few of them seemed acceptable, if we are really expecting any single
one of them to potentially not be available, it isn't looking good.

What about doing in the beginning of the file something like:

/*
 * Define dummy syscall numbers for systems not supporting them
 */

#ifndef __NR_whatever
#define __NR_whatever -1
#endif

#ifndef __NR_some_exotic_syscall
#define __NR_some_exotic_syscall -2
#endif

The negative number would never match, we may add a mostly
insignificant overhead checking for it but we keep the function
readable. What do you think?

I'm not sure if we can get the compiler rid of it completely, but it's
probably not worth it.

What do you think?

Thanks,
Gabriele

> ---
>  kernel/trace/rv/monitors/sleep/sleep.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/trace/rv/monitors/sleep/sleep.c
> b/kernel/trace/rv/monitors/sleep/sleep.c
> index eea447b06907..c1347da69e9d 100644
> --- a/kernel/trace/rv/monitors/sleep/sleep.c
> +++ b/kernel/trace/rv/monitors/sleep/sleep.c
> @@ -127,7 +127,9 @@ static void handle_sys_enter(void *data, struct
> pt_regs *regs, long id)
>  	mon = ltl_get_monitor(current);
>  
>  	switch (id) {
> +#ifdef __NR_clock_nanosleep
>  	case __NR_clock_nanosleep:
> +#endif
>  #ifdef __NR_clock_nanosleep_time64
>  	case __NR_clock_nanosleep_time64:
>  #endif
> @@ -138,7 +140,9 @@ static void handle_sys_enter(void *data, struct
> pt_regs *regs, long id)
>  		ltl_atom_update(current, LTL_CLOCK_NANOSLEEP, true);
>  		break;
>  
> +#ifdef __NR_futex
>  	case __NR_futex:
> +#endif
>  #ifdef __NR_futex_time64
>  	case __NR_futex_time64:
>  #endif


  reply	other threads:[~2025-08-05  6:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04 19:45 Palmer Dabbelt
2025-08-05  6:18 ` Gabriele Monaco [this message]
2025-08-05 12:12   ` Nam Cao

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=580bf2db57cefa07631e73e5af453228cfb3cecb.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=namcao@linutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=rostedt@goodmis.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®