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

Re: [XEN PATCH][for-4.19 v2 1/1] xen: introduce a deviation for Rule 11.9


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 17 Oct 2023 08:51:27 +0200
  • 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=Ry6UbNeoxsnonY9lAwDQb65Wy4a9o21j6VWdkv7ewyA=; b=E2vmo78k+NkjS4oY0FThVQ/j9CI560lKkuzvsmmVnhB1SfjakgNSh4Tq5XspDwhxI/P1XPaMK2P/p+LaQZfHfV6CnwqAI97qb87VOC/gMrLS47MFNOCzOoUY/hm+tQGAAtI1EldQFIArD/94fuwVImjNvA+zLQ8+HuBZoPajYKf9T6KtTXTab81KYyr31Jr8cOJebbhxAZEBKhNRSIYQaDTSMYg0OSznUOpN62NJ6ep512WbMtJ7Cx4VWwIRfwUjGqPgAKmZWJsqTsEF1VEA7UGOnOqbLu1XKNjf1760jopa+10VLxmtFrHz3pSKyvlfYVKd3r+Rxir6oedKSe3mew==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cESuwN5Yw4ZlFZdaED9+EvMNn2JAYK8A4mnhC8yrKYYQ+PJoOu2spupe02I7jcPuLHZ1adHyXsRMPpdw7KA6KxjcchxPfuPY9pWxPlxyHDUvKTFpP5pe46ECvHevKFOJIPeItShoJ5K9oAE2K3ozy/8fs+zO9joYgMto0Ptgio8dBbOyzqJ8B3iso3Wg83MIQPS57pVdFYaCsCsiU5Vi9OSgJJyOs4cFZCitS5UpgG7pGUTMvgm0SAp5v1ETHQhL0y1WbP0DKUnK6kdN1xAKGWquOuljk3wS5eI/L7i0QBw1R06NalXxDhffDJy9bFCATJsRLq26wPR/DqecdPZDAw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 17 Oct 2023 06:51:40 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 16.10.2023 18:49, Nicola Vetrini wrote:
> On 16/10/2023 15:43, Jan Beulich wrote:
>> On 11.10.2023 14:46, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/compiler.h
>>> +++ b/xen/include/xen/compiler.h
>>> @@ -109,13 +109,16 @@
>>>
>>>  #define offsetof(a,b) __builtin_offsetof(a,b)
>>>
>>> +/* Access the field of structure type, without defining a local 
>>> variable */
>>> +#define access_field(type, member) (((type *)NULL)->member)
>>
>> This is not a field access, so I consider the macro misnamed. Question 
>> is
>> whether such a helper macro is needed in the first place.
>>
>>> +#define typeof_field(type, member) typeof(access_field(type, member))
>>
>> If this needs adding, it wants to come ...
>>
>>>  /**
>>>   * sizeof_field(TYPE, MEMBER)
>>>   *
>>>   * @TYPE: The structure containing the field of interest
>>>   * @MEMBER: The field to return the size of
>>>   */
>>> -#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER))
>>> +#define sizeof_field(TYPE, MEMBER) sizeof(access_field(TYPE, MEMBER))
>>
>> ... with a commend similar as this one has. (Or the commend could be
>> slightly altered to cover both).
>>
> 
> I added access_field since it's possibly useful on its own in the 
> future,
> but that may not be the case. Not a real field access, perhaps a 
> fake_access_field?

I don't like this either, I'm afraid: This isn't a fake access. Maybe
field_of() or field_of_type()? Yet at this point I'd still prefer for
this to not be a separate macro in the first place.

Jan



 


Rackspace

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