[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection



On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote:
> On 17.04.2020 15:19, Anthony PERARD wrote:
> > Or do you mean keeping exception to the rule? And hope that when someone
> > changes the rule, it doesn't forget to check if the exception needs
> > changing as well?
> 
> ... "exception" like you put it (requiring special care to keep
> multiple instances in sync) is not the only way this can be done
> (and indeed I'd not want something like this). Since you have
> (in patch 15) e.g.
> 
> guest_walk_%.o: guest_walk.c FORCE
>       $(call if_changed_rule,cc_o_c)
> 
> anyway, the desire to skip the objcopy step could be communicated
> to the command from here, without needing to clone the command.
> One way might be a special (phony) dependency, another might be to
> set some variable along the lines of
> 
> guest_walk_%.o: SPECIAL := y

I guess something like that could be done. But if possible, I'd like to
avoid that.

> > Also, I'm going to have to use this patch later anyway as sometime CC
> > use a full path to the source as file symbol. So this is going to be
> > important when we will run for example
> > `clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`.
> > (There isn't a patch for that yet.)
> 
> That's interesting - what will be the goal of that future adjustment?

It's a step toward my goal of been able to have out-of-tree build for
xen, as stated in my cover letter. In order to do that, I try to adapt
Kbuild to build Xen.

Kbuild is building the linux kernel without changing directory, so I'd
like to do the same, as it probably makes it easier to do out-of-tree
build.

Another tool I'd like to use from Kbuild is ./fixdep, it's a small
program that run after running CC and fix the dependency file that CC
generates. The main thing it does is to add a dependency on
Kconfig options that a source file uses instead of having a dependency
on whether any unrelated Kconfig has change at all. But ./fixdep from
Linux only works if we build without changing directory. ([1] for more
on fixdep)

I guess one advantage of never changing directory is that we can always
use relative path in global *FLAGS. There isn't a need to use absolute
path, which is an issue when the source tree is moved to a different
location. That can easily happen when for example you try to build in a
container (mapping the source tree inside it) then try to rebuild from
outside. (After using automation/scripts/containerize for example.)
And we don't need tricks like the .*.d2 files (which isn't needed in the
hypervisor anyway, so far at least).


[1], copied from Linux's scripts/basic/fixdep.c introduction:
    If the user re-runs make *config, autoconf.h will be
    regenerated.  make notices that and will rebuild every file which
    includes autoconf.h, i.e. basically all files. This is extremely
    annoying if the user just changed CONFIG_HIS_DRIVER from n to m.

    So we play the same trick that "mkdep" played before. We replace
    the dependency on autoconf.h by a dependency on every config
    option which is mentioned in any of the listed prerequisites.

    kconfig populates a tree in include/config/ with an empty file
    for each config symbol and when the configuration is updated
    the files representing changed config options are touched
    which then let make pick up the changes and the files that use
    the config symbols are rebuilt.

    So if the user changes his CONFIG_HIS_DRIVER option, only the objects
    which depend on "include/config/his/driver.h" will be rebuilt,
    so most likely only his driver ;-)

-- 
Anthony PERARD



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.