public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	LKML <linux-kernel@vger.kernel.org>,
	jdike@addtoit.com
Subject: Re: asm-offsets.h is generated in the source tree
Date: Sun, 11 Sep 2005 19:04:25 +0200	[thread overview]
Message-ID: <20050911170425.GA8049@mars.ravnborg.org> (raw)
In-Reply-To: <20050911154550.GJ25261@ZenIV.linux.org.uk>

> > > What happens:
> > > 	a) silentconfig expects to have include/linux in build tree already
> > > created.  Normally that happens earlier, but only by accident.  We need to
> > > force that somehow and the way I'd done it is almost certainly wrong - it
> > > should be in top-level makefile, to start with.  Suggestions?
> > 
> > We could stick a `mkdir -p include/linux` command just before executing
> > $(Q)$(MAKE) $(build)=scripts/kconfig silentoldconfig
> > 
> > It should do the trick - no?
> 
> AFAICS that would do it and it would make sense - silentoldconfig really
> relies on it being there, so it's either a dependency or just forcing it
> to be there.  Either would do and it certainly belongs to top-level Makefile.
I will include this in next patch series. This is a fix so it should be
ok for post monday.

> > > 	b) kernel-offsets.h needs symlinks already in place.  prepare1 does
> > > everything we need, so that dependency is probably the right thing (the second
> > > chunk).
> > 
> > I will try to take a closer look at this tonight.
What I have done in my tree is to set up following dependency tree in
the top-lvel Makefile:

prepare
  +-prepare0
     +-archprepare
        +-prepare1
           +-prepare2
              +-prepare3


prepare0 needs archprepare, but archprepare may need prepare1.
So this should be OK on all architectures.
And you can go back relying solely on prepare in um Makefile.


> > As always my head starts spinning when I look at the arch/um/Makefile
> > but I will see what I can do.
> > If I can simplify it and introduce full dependency checks it would be
> > really nice. 
...
> No need.  We really need only two generated files - constants from
> UML host userland and constants from UML kernel itself.  That's it.
> 
> And these are needed since we have two parts of UML code - built with
> kernel and userland headers resp. (basically, normal kernel code and
> glue to UML host userland).  Since headers really do not mix, we have
> to use extracted constants in pretty much the same way we have to
> do that for assembler bits.  So there you go...
It certainly look much much better than anything I could come up with.
You should persuade Jeff and Paolo to test and include this.

A few notes..
  
>  define filechk_gen-asm-offsets
>          (set -e; \
> -         echo "#ifndef __ASM_OFFSETS_H__"; \
> -         echo "#define __ASM_OFFSETS_H__"; \
>           echo "/*"; \
>           echo " * DO NOT MODIFY."; \
>           echo " *"; \
> @@ -208,8 +199,7 @@
>           echo " */"; \
>           echo ""; \
>           sed -ne "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /* \3 */:; s:->::; p;}"; \
> -         echo ""; \
> -         echo "#endif" )
> +         echo ""; )
>  endef
>  
>  include/linux/autoconf.h : include/linux/version.h
> @@ -220,49 +210,18 @@
>  $(ARCH_DIR)/user-offsets.s: $(ARCH_DIR)/sys-$(SUBARCH)/user-offsets.c
>  	$(CC) $(USER_CFLAGS) -S -o $@ $<

This part could be moved to a Kbuild file so we have access to
full kbuild functionality - and thus anebling full dependency check
on user-offset.c
  
> -$(ARCH_DIR)/user-offsets.h: $(ARCH_DIR)/user-offsets.s
> +$(ARCH_DIR)/include/user_constants.h: $(ARCH_DIR)/user-offsets.s
>  	$(call filechk,gen-asm-offsets)
filechk is only relevant if there is a risk that user_constants.h is
rebuild but there is no changes in output file. We do this for version.h
but I do not see any big need for it here.
  
> -$(ARCH_DIR)/kernel-offsets.h: $(ARCH_DIR)/kernel-offsets.s
> +$(ARCH_DIR)/include/kern_constants.h: $(ARCH_DIR)/kernel-offsets.s
>  	$(call filechk,gen-asm-offsets)

Same comment as above.

	Sam

  reply	other threads:[~2005-09-11 17:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-10 15:20 asm-offsets.h is generated in the source tree Stephen Rothwell
2005-09-10 16:19 ` Sam Ravnborg
2005-09-11  2:32   ` Al Viro
2005-09-11  8:31     ` Sam Ravnborg
2005-09-11 15:45       ` Al Viro
2005-09-11 17:04         ` Sam Ravnborg [this message]
2005-09-11 21:29           ` Al Viro
2005-09-11 22:03             ` Sam Ravnborg
2005-09-11 23:16               ` Al Viro
2005-09-12 19:15                 ` Sam Ravnborg
2005-09-13  6:30                   ` Al Viro
2005-09-13  6:48                     ` Kyle Moffett
2005-09-13  6:53                       ` Keith Owens
2005-09-13  6:58                         ` Kyle Moffett
2005-09-13 21:55                     ` Al Viro
2005-09-15  1:07                   ` Al Viro
2005-09-10 19:08 ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050911170425.GA8049@mars.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=jdike@addtoit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox