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

Re: [Xen-devel] [PATCH v2] CODING_STYLE: document intended usage of types

  • To: George Dunlap <george.dunlap@xxxxxxxxxx>
  • From: Jan Beulich <JBeulich@xxxxxxxx>
  • Date: Mon, 5 Aug 2019 13:19:35 +0000
  • Accept-language: en-US
  • 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-SenderADCheck; bh=NzB8Z2nBme+bwgG064RFeStFu7OvzGBQgk0v6+nC/Ww=; b=HDG4ch7aISW4VJsCPsrk7lG47lt0b6ALIzZNGw8CPk3BG8io3vwVuF9GeCpOluP0TN50i5F8NBksn0CWsoSrApTeddtH0L7j6cdYJGpuMz1Jc64gQ55E+JhJt0YOWR5PDYEB8wngbMdj3yAsCOyL0rv29pDeQv1LQD+4mVBgOOGqmB0faHE2Pv84b9OGtueHX9OEZt5DWyYgJZNBtUvVoSFqKnrMEbD1zmF6+4nQbuuLo/oIA6Eg5ooUUelHymvXtU/g1yJ+XKfs3hLre7dwqQEB2TDhcEb2fQGnu8AwccKYE2pPsZm3GQ2J1Lgv+KPZv+ZZcqvvTV76+9yLHKyYjw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TC8GcKZsKJuj0MUODEkx4q0BbhDpA9vI590KbvokPuuRukcKUdcIu2VNV44t2oYet9gXel0fdiuy6cKlc4RP0QBP/t2Gq/8J2l1QLbnNb0ulc83EWCALCApuzCmMXr7GZIUrWpn8cylofpT8DAzc+2ZO7ytR0LPz1XEow5WR/tZRhddq2qSfW2mznfNQ3XBUfz/fVwswZhgHxudcxOoJj9/N3tYA88j9KM4+m1wWOkHbp/VC2PunogRN1yTt+c3l8i41gEW2fwAvtXwPiR3M72TLtrFtWGUh305IAa+rDjnJqLGq+YC6/6eYvtE896QnbRtAG5uQqn2mPcJX5K1hlA==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, IanJackson <Ian.Jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 05 Aug 2019 13:21:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVS3zWhCjk0U9++E+I/4nSrlmXN6bsk+CA///xMbKAAATGAA==
  • Thread-topic: [Xen-devel] [PATCH v2] CODING_STYLE: document intended usage of types

On 05.08.2019 15:01, George Dunlap wrote:
> On 8/5/19 12:55 PM, Jan Beulich wrote:
>> On 05.08.2019 12:58, George Dunlap wrote:
>>> On 11/26/18 9:31 AM, Jan Beulich wrote:
>>>> +Fixed width types should only be used when a fixed width quantity is
>>>> +meant (which for example may be a value read from or to be written to a
>>>> +register).
>>> I'm having trouble understanding the intent / implications of this one.
>>>    Can you give me an example of where you've seen a fixed width type used
>>> inappropriately?
>> Grep the code base for "uint32_t size" for example. These should
>> (almost?) all be unsigned int (or, where necessary, size_t).
> Inside the hypervisor codebase anyway, I see these patterns for
> `uint32_t size`:
> 1. Inside tracing structures, where the code may be used either by
> 32-bit or 64-bit userspace tools

I simply assume in these cases use of fixed width types is

> 2. Inside headers for public interfaces (same reason).

Here fixed width types are definitely the right choice.

> 3. In function signatures for emulation code.  I assume this is because
> sizes are architecturally defined.

Taking null_read() as an example - no, there's no need for a fixed
width type here. Even if the value was read from a register,
propagating the value still only needs to guarantee no truncation.
But the value can't come from a register directly anyway, or else
the type would need to be uint64_t. The type "addr" is wrongly
using uint64_t here, too, in my opinion: It should be unsigned long
or paddr_t, depending on whether we're talking of linear or physical
addresses (I think it's the latter here).

> 4. Inside decompression code, to interface with public sizes.

I don't think there's any interfacing with "public" structures

5. sysctl_cov_op() should again use unsigned int
6. struct elf_sym_header too should use unsigned int
7. struct hvm_domain_context may want to continue to use uint8_t
    (albeit unsigned char would be quite fine as well), but its
    two uint32_t uses could once again be unsigned int

Xen-devel mailing list



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