From: John Kacur <jkacur@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Oscar Shiang <oscar0225@livemail.tw>,
williams@redhat.com, linux-rt-users@vger.kernel.org
Subject: Re: [PATCH] rt-numa: Correct the comment of numa_initialize()
Date: Sat, 25 Dec 2021 11:58:51 -0500 (EST) [thread overview]
Message-ID: <fdfe2f7-c4f8-b8fc-c31d-ab2190c262b@redhat.com> (raw)
In-Reply-To: <YcSdzd3jmjV/rxBB@linutronix.de>
On Thu, 23 Dec 2021, Sebastian Andrzej Siewior wrote:
> On 2021-12-23 22:01:07 [+0800], Oscar Shiang wrote:
> > --- a/src/lib/rt-numa.c
> > +++ b/src/lib/rt-numa.c
> > @@ -15,7 +15,7 @@
> >
> > /*
> > * numa_available() must be called before any other calls to the numa library
> > - * returns 0 if numa is available, or 1 if numa is not available
> > + * returns 1 if numa is available, or 0 if numa is not available
> > */
>
> To quote the man page:
>
> Before any other calls in this library can be used numa_available()
> must be called. If it returns -1, all other functions in this library
> are undefined.
>
> Based on that, neither 0 nor 1 is defined.
>
> Sebastian
>
Right, but the numa_initialize function is meant to wrap that in such a
way that we only call numa_available once, and then subsequent calls will
return 1 (or true) for numa is available or 0 (false) if it is not
available. This wrapper could probably be omitted, but it's supposed
to make the code more readable.
This still isn't entirely cleaned up after this functionality
was removed during the JSON stuff that mistakenly assumed numa is always
available at runtime. (it might not be for example on some embedded
platforms). In some case there might still be paths through the code that
don't call non-numa versions of the functions when numa is not available.
It's on my list to fix.
John
next prev parent reply other threads:[~2021-12-25 16:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-23 14:01 [PATCH] rt-numa: Correct the comment of numa_initialize() Oscar Shiang
2021-12-23 16:03 ` Sebastian Andrzej Siewior
2021-12-25 7:17 ` Oscar Shiang
2021-12-25 16:58 ` John Kacur [this message]
2021-12-25 16:43 ` John Kacur
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=fdfe2f7-c4f8-b8fc-c31d-ab2190c262b@redhat.com \
--to=jkacur@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=oscar0225@livemail.tw \
--cc=williams@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox