From: Jan Beulich <jbeulich@suse.com>
To: Oleksii <oleksii.kurochko@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Gianluca Guida <gianluca@rivosinc.com>,
George Dunlap <george.dunlap@citrix.com>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org,
Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME
Date: Thu, 23 Feb 2023 14:25:32 +0100 [thread overview]
Message-ID: <567cd948-3968-88ff-d4ed-6d5fb65a46dd@suse.com> (raw)
In-Reply-To: <9d2bbf1821459cbc5c294261a34728cd8aaf99c1.camel@gmail.com>
On 23.02.2023 14:16, Oleksii wrote:
>>
>>> + void (*fn)(const struct cpu_user_regs *) = (void *)regs-
>>>> BUG_FN_REG;
>>
>> ... this, wouldn't it be better (and independent of the specific
>> arch) if
>> you checked for BUG_FN_REG being defined?
>>
>> Another (#ifdef-free) variant would be to have bug_ptr() take a 2nd
>> argument
>> and then uniformly use ...
>>
>>> +#else
>>> + void (*fn)(const struct cpu_user_regs *) = bug_ptr(bug);
>>
>> ... this, slightly altered to
>>
>> void (*fn)(const struct cpu_user_regs *) = bug_ptr(bug,
>> regs);
> I think that I will go with BUG_FN_REG instead of changing bug_ptr()'s
> arguments as bug_ptr() is used below to get file name so it won't be
> clear what bug_ptr() should return either an address of file name or
> regs->BUG_FN_REG.
Oh, indeed - I'm sorry that I didn't pay attention to ...
>>> +#endif
>>> +
>>> + fn(regs);
>>> + return 0;
>>> + }
>>> +
>>> + /* WARN, BUG or ASSERT: decode the filename pointer and line
>>> number. */
>>> + filename = bug_ptr(bug);
>>> + if ( !is_kernel(filename) && !is_patch(filename) )
... this 2nd use.
Jan
next prev parent reply other threads:[~2023-02-23 13:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 16:40 [PATCH v2 0/4] introduce generic implementation of macros from bug.h Oleksii Kurochko
2023-02-20 16:40 ` [PATCH v2 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME Oleksii Kurochko
2023-02-22 12:46 ` Jan Beulich
2023-02-22 16:16 ` Oleksii
2023-02-23 10:11 ` Jan Beulich
2023-02-23 12:14 ` Oleksii
2023-02-23 13:16 ` Oleksii
2023-02-23 13:25 ` Jan Beulich [this message]
2023-02-23 13:32 ` Jan Beulich
2023-02-23 15:09 ` Oleksii
2023-02-20 16:40 ` [PATCH v2 2/4] xen: change <asm/bug.h> to <xen/bug.h> Oleksii Kurochko
2023-02-23 13:34 ` Jan Beulich
2023-02-23 15:14 ` Oleksii
2023-02-20 16:40 ` [PATCH v2 3/4] xen/arm: switch ARM to use generic implementation of bug.h Oleksii Kurochko
2023-02-20 16:41 ` [PATCH v2 4/4] xen/x86: switch x86 to use generic implemetation " Oleksii Kurochko
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=567cd948-3968-88ff-d4ed-6d5fb65a46dd@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=gianluca@rivosinc.com \
--cc=julien@xen.org \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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 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.