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

Re: [PATCH v1 5/5] CODING_STYLE: add .clang-format


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 1 Dec 2022 12:52:11 +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=6g/ul4qbhNIp+YifkeZmyCzfUjU1gLa6XUqRzHUN97I=; b=ckQ/3yDT+MbkJnv4MHE1PK8g1WvdqId7CpSVfJrIFpzf6ycy77vfLdgIt6tPkGbVZIO+dyvLzzand5sziVO34G1r6XhAN55hA0MKeIAnJTkLdoMw9WyUFQ1ali0ijfa9fcxKIUjZ3ceSHotns/jbviD1fdwkEBkDXVhpyfGxuoDgX2os8cUQY7IuQ6M1oOqB21g5rgOIck7TdPW/9MFie+Fx2E8pOzkD0wcojI3RQ7Pfg+/a4siCiuXNyhZv7c4eB1PkQNCtN7/vqNKpr3u++Fdo4JV6hbL07gT52vp9P7xOG7C4Cm2QMfhZnyHv7yLgQypT/FkbVV/jNzKMsrxAXg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D/QnbpN8nvSsCThcV8ajzBlTqA3HVXSwViJyUwfzJ/25rj1iI0LRBnldWh4fbtnnwiGojsQhhdJ0fFOaRyptwmWQQqQw0repKAwaL0EfMNQ8PUeSQdDvzb7bcXWmkbcvy5CDlZpyQxfKhj1v2QPFOMypOosMdOBHAD5nWhwPG4j9LQIyFTOklJQIohKH50eapDLosyzDCGkr1vDm8E757dGK2JW+eHoqW+NeWObSV4f08ir3jzixPYHqiCLqLyWqUmKCsbPVLphawBC/6R/tuxR4sjF7SGOthPhMznAvtBzX9aa2+BS+9VmPtSa0LAug1u6L/uJy291kMC4fiIECow==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Christian Lindig <christian.lindig@xxxxxxxxxx>, David Scott <dave@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Edwin Torok <edvin.torok@xxxxxxxxxx>
  • Delivery-date: Thu, 01 Dec 2022 11:52:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.12.2022 12:35, Julien Grall wrote:
> On 01/12/2022 11:30, Jan Beulich wrote:
>> On 01.12.2022 11:47, Julien Grall wrote:
>>> On 01/12/2022 10:44, Juergen Gross wrote:
>>>> On 01.12.22 11:12, Julien Grall wrote:
>>>>>> We might want to add a comment to xs_wire.h like the one in ring.h in
>>>>>> order to
>>>>>> document the requirement of the type definition of uint32_t.
>>>>>
>>>>> The problem with this approach is you made more difficult for any
>>>>> userspace application to use the headers. So I would argue that the
>>>>> Linux copy can remove "stdint.h" if needed.
>>>>
>>>> Today there is exactly one public header including stdint.h, and I'd argue
>>>> that this was a mistake.
>>
>> I think so, too.
>>
>>>> xs_wire.h is especially rather uninteresting for any user space application
>>>> but a Xenstore implementation. All consumers of xs_wire.h are probably
>>>> either in the Xen tree, or operating system kernels. User space
>>>> applications
>>>> should use libxenstore for accessing the Xenstore, so I don't see an
>>>> advantage in breaking the usual philosophy of the Xen public headers NOT
>>>> including external headers like stdint.h.
>>>
>>> I think Edwin example is a pretty good justification for including
>>> stdint.h.
>>
>> I disagree. The intention has always been for consumers to provide the
>> basic C99 types by whatever suitable means they have. Note that in Xen
>> we also have no stdint.h.
> 
> I really dislike when I have to find the dependency of an header. This 
> is really a waste of time...

I can see your point, but for Xen's public headers it has always been
that way. Plus, as said, adding (unguarded) #include <stdint.h> would
even break the building of Xen itself.

> If other disagree with that, then the strict minimum would be for this 
> dependency to be recorded if it hasn't been done (I couldn't find anywhere).

It is kind of recorded in xen/include/Makefile, with the three
"-include stdint.h" that are used there (of which one probably really
ought to be -include cstdint). But I agree this can't really count as
documentation.

>>> If you have a coding style requiring to order header alphabetically,
>>> then the developer may not even be able to include stdint.h without any
>>> hackery (e.g. introducing a header that will always be before the Xen
>>> public headers).
>>
>> Just to indicate that commonly style requirements may be weaker than
>> "fully alphabetic" - we don't request full ordering. What we request is
>> that groups (xen/, asm/, public/) be ordered within any group, but we
>> do not (afaia) demand ordering across groups (and indeed commonly we
>> have asm/ after xen/).
> Right, but that's **our** coding style. You don't know what's going to 
> be the coding style for other project.

Sure, hence me having said "may be" in my reply.

Jan



 


Rackspace

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