Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object 
files directly"):
> On 20.09.16 at 02:19, <boris.ostrovsky@xxxxxxxxxx> wrote:
> > --- a/tools/firmware/hvmloader/acpi/Makefile
> > +++ b/tools/firmware/hvmloader/acpi/Makefile
> > @@ -15,41 +15,45 @@
> >  XEN_ROOT = $(CURDIR)/../../../..
> >  include $(XEN_ROOT)/tools/firmware/Rules.mk
> >  
> > -C_SRC-$(GPL)       = build.c dsdt_anycpu.c dsdt_15cpu.c 
> > dsdt_anycpu_qemu_xen.c
> > -C_SRC              = build.c static_tables.c $(C_SRC-y)
> > -OBJS  = $(patsubst %.c,%.o,$(C_SRC))
> > +# Used as a workaround for a bug in some older iasl versions where
> > +# the tool will ignore everything after last '.' in the path ('-p' 
> > argument)
> > +TMP_SUFFIX = tmp__
> 
> Hmm, the comment leaves open what newer iasl does? I suppose it
> strips everything after the last . too, but only if that ones comes
> after the last path separator?

I think Boris's approach ensures that the last . always comes after
the last path separator.

> It took me a moment to understand
> that no file with this suffix will ever be created, if my above summary
> is right. Please clarify this in the comment.

I'm not sure it's really helpful to put this TMP_SUFFIX thing in a
make variable but maybe Jan prefers it that way.

In any case I think the choice of `tmp__' is rather odd.  AFAICT the
resulting iasl command lines look like this:

  iasl -vs -p /path/to/here/blah.tmp__ -tc /path/to/here/blah.asl

I think `.dummy' would be a better string, if indeed it's a string
which we expect always to be stripped, and not to appear in any
filenames.

ian.

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