|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 06/10] x86: Introduce a new function to get capability of Intel PT
>>> On 04.07.18 at 10:48, <luwei.kang@xxxxxxxxx> wrote:
>> >> > +#define IPT_CAP(_n, _l, _r, _m) \
>> >> > + [IPT_CAP_ ## _n] = { .name = __stringify(_n), .leaf = _l, \
>> >> > + .reg = _r, .mask = _m }
>> >> > +
>> >> > +static struct ipt_cap_desc {
>> >> > + const char *name;
>> >> > + unsigned int leaf;
>> >> > + unsigned char reg;
>> >>
>> >> I don't think leaf needs to be full 32 bits wide? Once shrunk by at
>> >> least two bits, the size of the overall structure could go down from 24
>> >> to 16 bytes.
>> >
>> > OK, will change it from " unsigned int " to "unsinged char".
>>
>> I'd prefer if you used bit fields, as was meant to be implied by my reply.
>
> like this? If two bits is too few for "leaf"?
>
> static const struct ipt_cap_desc {
> const char *name;
> unsigned char leaf:2;
> unsigned char reg:2;
> unsinged int mask;
> }
Yes. As suggested before I'd use more bits for leaf, to avoid this
needing to change immediately once a new leaf becomes known.
After all the goal is only to have leaf and reg together fit in 32
bits. Making leaf 8 bits wide for now would likely help generated
code. And please don't use unsigned char in cases like this where
you don't really need the more narrow type - be as close to what
the standard allows without extensions as possible; IOW
unsigned int here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |