Re: [Xen-devel] [PATCH RFC] firmware/shim: fix Xen tree setup

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Feb 06, 2018 at 05:45:18AM -0700, Jan Beulich wrote:
> >>> On 06.02.18 at 13:36, <wei.liu2@xxxxxxxxxx> wrote:
> > On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
> >> - Excluding symlinks in the source tree is a problem for me: Short of
> >>   out-of-tree builds, in order to easily build test multiple
> >>   configurations, I'm setting up my build trees as trees of symlinks
> >>   into the source tree. Hence the original logic would find only the few
> >>   generated files under config/. I do realize though that find's -xtype
> >>   primary is a non-standard extension (explicitly having "! type -l"
> >>   seems pointless though, at least for standard conforming find, as
> >>   "-type f" is supposed to only find non-symlinked files).
> >> 
> > 
> > At the time I thought whatever symlinks we have in tree should be
> > created by xen's build system itself hence there was no need to copy
> > them around, and it would have to avoid latent problem like linking to
> > wrong files etc.
> > 
> > I think you have valid usecase for symlinks, so I'm fine with the change
> > you make.
> 
> The only symlinks I'm aware of are the ones putting some files from
> common/efi/ into arch/*/efi/. These are relative ones, so I was
> considering whether perhaps we should skip those but treat absolute
> ones like ordinary files. Do you have any opinion in that direction?

No opinion.

> 
> >> Irrespective of the changes I'm still observing "mkdir -p" to report a
> >> missing operand, as config/ has no subdirs. Oddly enough this doesn't
> >> cause the whole command (and hence the build to fail), despite the
> >> "set -e" now covering the entire set of commands - perhaps a quirk of
> >> the relatively old bash I've seen this with (a few simple experiments
> >> suggest that commands inside () producing a non-success status would
> >> exit the inner shell, but not the outer one).
> > 
> > I did see error when I wrote this bit hence I specifically hacked the
> > rune to preserve "." in the output. We can add that back if necessary.
> 
> Why was it dropped?

Because a few people touched this bit.

> 
> > I suppose you will send out a new version at some point?
> 
> Sure - I only need to (a) be clear about what changes to make and
> (b) find the time. Hopefully things will be easier once the Spectre v2
> backports are all done.
> 

OK. If you want me to help please let me know.

Wei.

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