Re: [Xen-devel] [PATCH v6 01/12] xen: allow only sizeof(bool) variables for boolean_param()

[Jürgen Groß <jgross@xxxxxxxx>]

On 09.03.20 14:06, Jan Beulich wrote:
> On 09.03.2020 14:01, Jürgen Groß wrote:
> > On 09.03.20 12:55, Jan Beulich wrote:
> > > On 09.03.2020 12:43, Julien Grall wrote:
> > > > On 26/02/2020 12:46, Juergen Gross wrote:
> > > > > @@ -46,7 +48,8 @@ extern const struct kernel_param __param_start[], 
> > > > > __param_end[];
> > > > >         __kparam __setup_##_var = \
> > > > >             { .name = __setup_str_##_var, \
> > > > >               .type = OPT_BOOL, \
> > > > > -          .len = sizeof(_var), \
> > > > > +          .len = sizeof(_var) + \
> > > > > +                 BUILD_BUG_ON_ZERO(sizeof(_var) != sizeof(bool)), \
> > > >    From my understanding, sizeof(bool) is not necessarily 1 (it can be
> > > > greater). While this is fine to use it in Xen, I think we want it to
> > > > always be one when exposed in the hypfs.
> > > I don't think so: We want variable of type 'bool' to be updated
> > > consistently (i.e. by a write to the full variable). Hence I
> > > think sizeof(bool) is correct here. I can see though that the
> > > hypercall interface then gains a dependency on the hypervisor's
> > > representation of 'bool', but I think such ought to be taken
> > > care of in the function carrying out the write, not in the
> > > macro here.
> > So you think I should special case bool entries when returning the
> > size information? Or do you think its fine to have the hypervisor's
> > size reported and let the lib do the size handling correctly?
> Either way would be fine by me, but I think not having callers have
> a (required) way to know the hypervisor's sizeof(bool) would be a
> more clean interface overall.
The size is reported via the dirent, so this is fine. And when you have
a look into patch 5 you'll see that the writing of the bool is merged
with the uint writing in the lib code. I should remove the safety check
regarding sizeof(bool) matching the size reported in the dirent, however
(this is a leftover I forgot to remove).


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel