Re: [Xen-devel] [PATCH v2] tools/firmware: add ACPI device for Windows laptop/slate mode switch

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 24 March 2017 11:16
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>; Owen Smith <owen.smith@xxxxxxxxxx>; Wei Liu
> <wei.liu2@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [PATCH v2] tools/firmware: add ACPI device for Windows
> laptop/slate mode switch
> 
> >>> On 24.03.17 at 12:04, <Paul.Durrant@xxxxxxxxxx> wrote:
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: 24 March 2017 10:53
> >> The only other concern I have here is that the abbreviation "conv"
> >> used throughout the patch is sort of ambiguous. I think it means
> >> "convertible" here, but without knowing the context it could easily
> >> be "conventional" or "convenience". Would there be anything
> >> wrong with spelling it out wherever name length limitations don't
> >> require it to be just four characters?
> >>
> >
> > I thought that name would be ok since it is the name of the ACPI device
> > itself but I could extend the xl.cfg option, bool and flag names to
> > 'acpi_convert' to make it more obvious.
> 
> Hmm, "convert" still leaves room for speculation (in particular, seeing
> an option with this name, I'd suspect it wants to convert ACPI to
> something else). Is that what "conv" stands for (and not "convertible"
> or anything else)?
> 

It was chosen simply because of the name of the device. How about 
'acpi_device_conv'? After all this option merely controls the inclusion of the 
device. Subsequent patches will have to add a PV protocol to instruct in-guest 
code to prod it.

  Paul

> Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel