[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/5] xen/xsm: Improve fallback handling in xsm_fixup_ops()


  • To: Andrew Cooper <amc96@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 18 Nov 2021 12:59:12 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xEIAbidNzS608OXD69nwjT0U5nhqnovo34e2SLoW5lc=; b=YQNrb2zYImw8/+LiahL0mKMh4msLfzruEHxfLPUajzzQYH/f6EJOFgyraPD4prIV72xzwthFfC7gdo/AYE1/+FNJCfEyyYfQxRHIzihE8XZEKU7c/Qhbueuw5qgyxg6RQOplmeOuB/bp+S6aTtTvsqNRhodfQ+9I9r9fLMs8UmFJI9NFuvmBIZ7CEEQIiG4IhQpFXMy8wMqCohKC+7qbDPta7iDmU2BrA1G85oJfikMHaMPGpwVizMGfw5D2uhUupPQwUlw7Kwhmoh+pfy506XqcNQXC3nNgGTzyXsypZPPv+XFe7s26N3Uf3nxZqBDuJdeoWzzr8sVY63CXNpWbTg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mYWkwFSH90baTQ2QwHyRZgvwRdNKKqh6IVMnOfENnzWdPM9dxevSXIH0TVysZ6IursjGVES7+pLRutFWGv3Gj1Vo7wIFYVO47hxLZQQYzWCTp5XRRJlKMna0RG8Ajp8zKU4MEvSW0dXDVz3rVEdVR0T1/uOQYGEJtYtDrGoUbP5j4hxCPRixwXGxV/hh00c+imRm89aZ8p7envrDV/mj4hRpNVA1yYHaqmBneI/UAAoFMWHEEAij03oRgc3JoPbCBVowm64M07GM8WA3zLHNSEvVC2aNlRNlFDgdhag6jfnyBkIP84lQZKzy4pHw8sHG66NWwEHxg89K41BcEeG5Sw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>, Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 18 Nov 2021 11:59:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.