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

Re: [PATCH 3/3] docs/doxygen: doxygen documentation for grant_table.h


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Luca Fancellu <luca.fancellu@xxxxxxx>
  • Date: Thu, 8 Apr 2021 12:02:24 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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-SenderADCheck; bh=RoOHmnX0gg8YRiRP8o155RWuUQDCfrPtauRDIXSX8II=; b=RiW9OW5dN0oi90rTzKvDnLm1o9mOveZGaBN9vST7qoubLALRRhsNSJJxuGrnYeH1qTKMLkFmEJh5crt3cF6cW/yftVVj+PeJAVf29pLTZv1soOt6aBe20tmfky2AGA3imui2nz+1G1+63+DGeYfi2BMak6x9l3rPqLJWo+ijP4aEmx1LOaVzSDwTWMpq4uYYCZaHLlZtT7QdV680aOh7SX4DDJaFT20KUvNsuL319NXvYSjr9goU/XIEZyPTtBGtZiMB2BwECpbDHsy+RrsRPKAJBSOkEo69WtKemdny1MXaZNXo269fx8abRJIBKBAZ19VjGbc736TqlThRPBJVWg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XW9vqalHepihQXl6b4RvxO4J9oChtOpkkefBhGCn+uOKNmmR19fc+TDN7KH0QlZB0XRuKUSNYg6+PLvbXGnJdMOtqyefcA7l530tfV0LkrQHJjyblib38h6TuHdT9UF7DCCHQuUKdaMIGmKkHW9jyrEsIh2kdtoPoZ5Izcd6c4GQKovj5JCSZNpa8HeDK/hn9xV29MGZGTKYxW6p1vswMf74m2pfz0qbQuBYCktS5YIJJ5M5Xz9XthZzrZLrr2yxiSS6QtsnolFogN6ErR/wq0Sinf+CIPQzqxS/RgSFM7p7uYt4AcFE1tEgIQVEdSf/KxaHwIiph2RX+YDtZIZ01A==
  • Authentication-results-original: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, wei.chen@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 08 Apr 2021 11:03:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=arm.com;


> On 7 Apr 2021, at 22:26, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Wed, 7 Apr 2021, Jan Beulich wrote:
>> On 07.04.2021 10:42, Luca Fancellu wrote:
>>> Just to be sure that we are in the same page, are you suggesting to modify 
>>> the name
>>> In this way?
>>> 
>>> struct gnttab_cache_flush {
>>> -    union {
>>> +    union xen_gnttab_cache_flush_a {
>>>        uint64_t dev_bus_addr;
>>>        grant_ref_t ref;
>>>    } a;
>>> 
>>> Following this kind of pattern: xen_<upper struct name>_<member name> ?
>> 
>> While in general I would be fine with this scheme, for field names like
>> "a" or "u" it doesn't fit well imo.
> 
> "a" is a bad name anyway, even for the member. We can take the
> opportunity to find a better name. Almost anything would be better than
> "a". Maybe "refaddr"?
> 
> 
>> I'm also unconvinced this would be
>> scalable to the case where there's further struct/union nesting.
> 
> How many of these instances of multilevel nesting do we have? Luca might
> know. Probably not many? They could be special-cased.

There are not many multilevel nesting instances of anonymous struct/union and 
the maximum level of nesting I found in the public headers is 2:

union {
        union/struct {
                …
        } <name>
} <name>

I also see that in the majority of cases the unions have not meaningful names 
like “a” or “u” as member name, instead struct names are fine,
It could be fine to keep the meaningful name the same for the struct type name 
and use the pattern for the non-meaningful ones as long
as the names doesn’t create compilation errors?

Example:

struct upper_level {
        union {
                struct {
                
                } meaningful_name1;
                struct {
                
                } meaningful_name2;
        } u;
};

becomes:

struct upper_level {
        union upper_level_u {
                struct meaningful_name1 {
                
                } meaningful_name1;
                struct meaningful_name2 {
                
                } meaningful_name2;
        } u;
};

Doing this will help a lot the documentation side because the html page will 
show the "struct upper_level" with inside the “union upper_level_u" and inside 
again 
the two struct “meaningful_name1" and “meaningful_name2", and from the point of 
view of the developer it can tell her/him exactly the name of the member to
access when writing code (apart from the upper_level_u that can be accessed by 
u, but we can’t clearly change it).
If this sounds difficult to understand when reading, please generate the 
documentation and have a look on the page in one side and the source code in 
another.

Moreover the change should be back-compatible since we are not changing member 
names.

Cheers,

Luca


 


Rackspace

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