All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <amc96@srcf.net>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	Daniel Smith <dpsmith@apertussolutions.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 4/5] xen/xsm: Improve fallback handling in xsm_fixup_ops()
Date: Thu, 18 Nov 2021 12:59:12 +0100	[thread overview]
Message-ID: <4c3b8d67-70e6-294b-5fea-a63b5a5eb77b@suse.com> (raw)
In-Reply-To: <1a9aae9f-fbe0-7c12-3a3c-222583a52b00@srcf.net>

On 17.11.2021 23:37, Andrew Cooper wrote:
> On 08/11/2021 09:04, Jan Beulich wrote:
>> On 05.11.2021 14:55, Andrew Cooper wrote:
>>> +void __init xsm_fixup_ops(struct xsm_ops *ops)
>>> +{
>>> +    /*
>>> +     * We make some simplifying assumptions about struct xsm_ops; that it is
>>> +     * made exclusively of function pointers to non-init text.
>>> +     *
>>> +     * This allows us to walk over struct xsm_ops as if it were an array of
>>> +     * unsigned longs.
>>> +     */
>>> +    unsigned long *dst = _p(ops);
>>> +    unsigned long *src = _p(&dummy_ops);
>> I'm afraid I consider this an abuse of _p(): It hides casting when
>> that would better not be hidden (and there's then also a pointless
>> step through "unsigned long" in the casting). I suppose this is
>> also why "src" didn't end up "const unsigned long *" - with spelled
>> out casts the casting away of const might have been more noticable.
> 
> I've changed to a const pointer, but opencoding _p() wouldn't make it 
> any more likely for me to have spotted that it ought to have been const 
> to begin with.
> 
> But ultimately it comes down to neatness/clarity.  This:
> 
> unsigned long *dst = _p(ops);
> const unsigned long *src = _p(&dummy_ops);
> 
> is easier to read than this:
> 
> unsigned long *dst = (unsigned long *)ops;
> const unsigned long *src = (const unsigned long *)&dummy_ops;
> 
> Fundamentally, I can do either, but I have a preference for the one 
> which is easier to follow.

One option would be to at least make _p() cast to const void *.

Jan



  reply	other threads:[~2021-11-18 11:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 13:55 [PATCH 0/5] XSM: cleanups Andrew Cooper
2021-11-05 13:55 ` [PATCH 1/5] x86/altcall: allow compound types to be passed Andrew Cooper
2021-11-05 14:09   ` Daniel P. Smith
2021-11-05 13:55 ` [PATCH 2/5] xen/xsm: Complete altcall conversion of xsm interface Andrew Cooper
2021-11-05 14:00   ` Jan Beulich
2021-11-05 14:11   ` Daniel P. Smith
2021-11-08  9:11   ` Jan Beulich
2021-11-17 22:22     ` Andrew Cooper
2021-11-05 13:55 ` [PATCH 3/5] xen/xsm: Drop xsm_hvm_control() hook Andrew Cooper
2021-11-05 14:20   ` Daniel P. Smith
2021-11-05 13:55 ` [PATCH 4/5] xen/xsm: Improve fallback handling in xsm_fixup_ops() Andrew Cooper
2021-11-05 14:22   ` Daniel P. Smith
2021-11-08  9:04   ` Jan Beulich
2021-11-17 22:37     ` Andrew Cooper
2021-11-18 11:59       ` Jan Beulich [this message]
2021-11-05 13:55 ` [PATCH 5/5] xen/xsm: Address hypercall ABI problems Andrew Cooper
2021-11-08  9:50   ` Jan Beulich
2021-11-17 23:14     ` Andrew Cooper
2021-11-17 23:20       ` Andrew Cooper
2021-11-18 13:01         ` Jan Beulich
2021-11-18 12:59       ` Jan Beulich

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=4c3b8d67-70e6-294b-5fea-a63b5a5eb77b@suse.com \
    --to=jbeulich@suse.com \
    --cc=amc96@srcf.net \
    --cc=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=dpsmith@apertussolutions.com \
    --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.