[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 |