* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
[not found] <20010811212051.A819@jaquet.dk>
@ 2001-08-12 2:11 ` Keith Owens
2001-08-12 2:27 ` Tom Rini
2001-08-12 7:31 ` [kbuild-devel] " Rasmus Andersen
0 siblings, 2 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 2:11 UTC (permalink / raw)
To: Rasmus Andersen; +Cc: Tom Rini, kbuild-devel, linux-kernel
On Sat, 11 Aug 2001 21:20:52 +0200,
Rasmus Andersen <rasmus@jaquet.dk> wrote:
>pp_makefile2: drivers/char/defkeymap.o is selected but is not part of vmlinux, missing link_subdirs?
Against 2.4.8 + kbuild-2.5-2.4.8-1. I will put up a -2 later today
containing this fix and a few others.
Index: 8.7/scripts/pp_makefile2.c
--- 8.7/scripts/pp_makefile2.c Sat, 11 Aug 2001 22:45:22 +1000 kaos (linux-2.4/I/d/36_pp_makefil 1.24 644)
+++ 8.7(w)/scripts/pp_makefile2.c Sun, 12 Aug 2001 11:43:58 +1000 kaos (linux-2.4/I/d/36_pp_makefil 1.24 644)
@@ -754,7 +754,10 @@ int special_oais(PP_DIRENT *dirent, PP_D
}
if (dirent->value.db) {
DB *db = db_list[dirent->value.db];
- if (!dirent->istarget) {
+ /* FIXME: when the go faster stripes are added, make sure that
+ * dirent->istarget and db->istarget are synced earlier.
+ */
+ if (!db->istarget && !dirent->istarget) {
return(0);
}
switch (type) {
>pp_makefile2: Cannot find source for target drivers/sound/emu10k1/efxmgr.o
>pp_makefile2: Cannot find source for target drivers/sound/emu10k1/joystick.o
>pp_makefile2: Cannot find source for target drivers/sound/emu10k1/passthrough.o
You put kbuild-2.5-2.4.8-1 on an 2.4.8-pre kernel. Linus moved emu10k1
to its own directory in 2.4.8. You have match kbuild with the correct
kernel.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 2:11 ` Announce: Kernel Build for 2.5, Release 1.1 is available Keith Owens
@ 2001-08-12 2:27 ` Tom Rini
2001-08-12 7:31 ` [kbuild-devel] " Rasmus Andersen
1 sibling, 0 replies; 22+ messages in thread
From: Tom Rini @ 2001-08-12 2:27 UTC (permalink / raw)
To: Keith Owens; +Cc: Rasmus Andersen, kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 12:11:27PM +1000, Keith Owens wrote:
> On Sat, 11 Aug 2001 21:20:52 +0200,
> Rasmus Andersen <rasmus@jaquet.dk> wrote:
> >pp_makefile2: drivers/char/defkeymap.o is selected but is not part of vmlinux, missing link_subdirs?
>
> Against 2.4.8 + kbuild-2.5-2.4.8-1. I will put up a -2 later today
> containing this fix and a few others.
k, thanks.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 2:11 ` Announce: Kernel Build for 2.5, Release 1.1 is available Keith Owens
2001-08-12 2:27 ` Tom Rini
@ 2001-08-12 7:31 ` Rasmus Andersen
2001-08-12 7:44 ` Keith Owens
1 sibling, 1 reply; 22+ messages in thread
From: Rasmus Andersen @ 2001-08-12 7:31 UTC (permalink / raw)
To: Keith Owens; +Cc: Tom Rini, kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 12:11:27PM +1000, Keith Owens wrote:
[...]
> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/efxmgr.o
> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/joystick.o
> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/passthrough.o
>
> You put kbuild-2.5-2.4.8-1 on an 2.4.8-pre kernel. Linus moved emu10k1
> to its own directory in 2.4.8. You have match kbuild with the correct
> kernel.
Yes, I have to and no, I did not. It was kbuild-2.5-2.4.8-1 on a
freshly untarred 248.tar.gz from a mirror. But kbuild-...-2 fixes
it for me fine.
--
Rasmus(rasmus@jaquet.dk)
"Give a man a fish, and he eats for a day. Teach a man to fish, and a
US Navy submarine will make sure he's never hungry again." -- Chris
Neufeld
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 7:31 ` [kbuild-devel] " Rasmus Andersen
@ 2001-08-12 7:44 ` Keith Owens
2001-08-12 7:57 ` Daniel T. Chen
0 siblings, 1 reply; 22+ messages in thread
From: Keith Owens @ 2001-08-12 7:44 UTC (permalink / raw)
To: Rasmus Andersen; +Cc: kbuild-devel, linux-kernel
On Sun, 12 Aug 2001 09:31:40 +0200,
Rasmus Andersen <rasmus@jaquet.dk> wrote:
>On Sun, Aug 12, 2001 at 12:11:27PM +1000, Keith Owens wrote:
>[...]
>> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/efxmgr.o
>> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/joystick.o
>> >pp_makefile2: Cannot find source for target drivers/sound/emu10k1/passthrough.o
>>
>> You put kbuild-2.5-2.4.8-1 on an 2.4.8-pre kernel. Linus moved emu10k1
>> to its own directory in 2.4.8. You have match kbuild with the correct
>> kernel.
>
>Yes, I have to and no, I did not. It was kbuild-2.5-2.4.8-1 on a
>freshly untarred 248.tar.gz from a mirror. But kbuild-...-2 fixes
>it for me fine.
Very strange, drivers/sound/emu10k1/efxmgr.c is definitely in 2.4.8 but
not in 2.4.8-pre. The corrected emu10k1 list in kbuild-2.5-2.4.8-2
added even more objects, but did not remove references to efxmgr. I
still think it was a bad source tree problem. Oh well, it is "fixed" now.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 7:44 ` Keith Owens
@ 2001-08-12 7:57 ` Daniel T. Chen
0 siblings, 0 replies; 22+ messages in thread
From: Daniel T. Chen @ 2001-08-12 7:57 UTC (permalink / raw)
To: Keith Owens; +Cc: Rasmus Andersen, linux-kernel
(not subbed to kbuild-devel, snipping)
On Sun, 12 Aug 2001, Keith Owens wrote:
> Very strange, drivers/sound/emu10k1/efxmgr.c is definitely in 2.4.8 but
> not in 2.4.8-pre. The corrected emu10k1 list in kbuild-2.5-2.4.8-2
> added even more objects, but did not remove references to efxmgr. I
> still think it was a bad source tree problem. Oh well, it is "fixed" now.
2.4.8-pre does not contain efxmgr.c, passthrough.c, and passthrough.h,
which were in development after v0.7 EMU10K1 was brought into the kernel.
dtc
---
Dan Chen crimsun@email.unc.edu
GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [kbuild-devel] Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
@ 2001-08-11 22:02 Tom Rini
2001-08-12 1:21 ` Keith Owens
4 siblings, 1 reply; 22+ messages in thread
From: Tom Rini @ 2001-08-11 22:02 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
> Changes from Release 1.
[snip]
> Document kbuild targets and C to assembler conversions. As always,
> Documentation/kbuild/kbuild-2.5.txt is your friend.
Okay, I've played with this a bit on PPC, and got it working to boot :)
Now here's what I see as the slight problems with it. At least on PPC
what we do is generate the offset bits, and then have another file,
arch/ppc/kernel/ppc_asm.h include that file and have some other useful
macros for .S files. So any of the .S files which include ppc_asm.h
would need an additional
extra_aflags(foo.o $(src_includelist /arch/$(ARCH)))
or extra_aflags_all($(src_includelist /arch/$(ARCH))
or my ugly workaround for the moment of #include <../arch/ppc/offsets.h>
which is wrong, but works.
But aside from that, it's nice that the file isn't generated every make
like it was w/ the user_command workaround :)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 22:02 [kbuild-devel] " Tom Rini
@ 2001-08-12 1:21 ` Keith Owens
2001-08-12 1:44 ` Tom Rini
2001-08-12 14:36 ` David Woodhouse
0 siblings, 2 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 1:21 UTC (permalink / raw)
To: Tom Rini; +Cc: kbuild-devel, linux-kernel
On Sat, 11 Aug 2001 15:02:55 -0700,
Tom Rini <trini@kernel.crashing.org> wrote:
>On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
>
>> Changes from Release 1.
>[snip]
>> Document kbuild targets and C to assembler conversions. As always,
>> Documentation/kbuild/kbuild-2.5.txt is your friend.
>
>Okay, I've played with this a bit on PPC, and got it working to boot :)
>Now here's what I see as the slight problems with it. At least on PPC
>what we do is generate the offset bits, and then have another file,
>arch/ppc/kernel/ppc_asm.h include that file and have some other useful
>macros for .S files. So any of the .S files which include ppc_asm.h
>would need an additional
>extra_aflags(foo.o $(src_includelist /arch/$(ARCH)))
That will be required for all asm code that includes offsets.h, on all
architectures, I doubt there will be more than 10 on any arch.
The alternative of having code in some arch directory updating
include/asm-$(ARCH)/offsets.h is worse. It is a terrible design to
have code in one makefile updating files in another directory. It is a
layer violation which is always a bad idea.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 1:21 ` Keith Owens
@ 2001-08-12 1:44 ` Tom Rini
2001-08-12 14:36 ` David Woodhouse
1 sibling, 0 replies; 22+ messages in thread
From: Tom Rini @ 2001-08-12 1:44 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 11:21:22AM +1000, Keith Owens wrote:
> On Sat, 11 Aug 2001 15:02:55 -0700,
> Tom Rini <trini@kernel.crashing.org> wrote:
> >On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
> >
> >> Changes from Release 1.
> >[snip]
> >> Document kbuild targets and C to assembler conversions. As always,
> >> Documentation/kbuild/kbuild-2.5.txt is your friend.
> >
> >Okay, I've played with this a bit on PPC, and got it working to boot :)
> >Now here's what I see as the slight problems with it. At least on PPC
> >what we do is generate the offset bits, and then have another file,
> >arch/ppc/kernel/ppc_asm.h include that file and have some other useful
> >macros for .S files. So any of the .S files which include ppc_asm.h
> >would need an additional
> >extra_aflags(foo.o $(src_includelist /arch/$(ARCH)))
>
> That will be required for all asm code that includes offsets.h, on all
> architectures, I doubt there will be more than 10 on any arch.
Hopefully not much more than 10, I hope.
> The alternative of having code in some arch directory updating
> include/asm-$(ARCH)/offsets.h is worse. It is a terrible design to
> have code in one makefile updating files in another directory. It is a
> layer violation which is always a bad idea.
Right. I figured it'd be worth pointing out, if nothing else.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 1:21 ` Keith Owens
2001-08-12 1:44 ` Tom Rini
@ 2001-08-12 14:36 ` David Woodhouse
2001-08-12 14:48 ` Keith Owens
1 sibling, 1 reply; 22+ messages in thread
From: David Woodhouse @ 2001-08-12 14:36 UTC (permalink / raw)
To: Keith Owens; +Cc: Tom Rini, kbuild-devel, linux-kernel
kaos@ocs.com.au said:
> The alternative of having code in some arch directory updating
> include/asm-$(ARCH)/offsets.h is worse. It is a terrible design to
> have code in one makefile updating files in another directory. It is
> a layer violation which is always a bad idea.
With sensible (i.e. non-recursive) makefiles, surely this is far more
acceptable?
--
dwmw2
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 14:36 ` David Woodhouse
@ 2001-08-12 14:48 ` Keith Owens
2001-08-12 14:56 ` David Woodhouse
2001-08-12 14:56 ` Russell King
0 siblings, 2 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 14:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: kbuild-devel, linux-kernel
On Sun, 12 Aug 2001 15:36:13 +0100,
David Woodhouse <dwmw2@infradead.org> wrote:
>
>kaos@ocs.com.au said:
>> The alternative of having code in some arch directory updating
>> include/asm-$(ARCH)/offsets.h is worse. It is a terrible design to
>> have code in one makefile updating files in another directory. It is
>> a layer violation which is always a bad idea.
>
>With sensible (i.e. non-recursive) makefiles, surely this is far more
>acceptable?
No. The aim is for a user to look at the makefile in a directory and
know everything that is created in that directory. If you allow
creation of a file in one directory but storing it in another then you
have to search all makefiles to find out what is created in any
directory. Horrible!
I was very careful to code the select() and objlink() and related
commands so they can only create files in the current directory, to
enforce a clean design. You can read a file from another directory but
you cannot write a file to another directory.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 14:48 ` Keith Owens
@ 2001-08-12 14:56 ` David Woodhouse
2001-08-12 14:56 ` Russell King
1 sibling, 0 replies; 22+ messages in thread
From: David Woodhouse @ 2001-08-12 14:56 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
kaos@ocs.com.au said:
> If you allow creation of a file in one directory but storing it in
> another then you have to search all makefiles to find out what is
> created in any directory. Horrible!
Fine. But what's stopping us from putting a makefile in the
asm-$(ARCH)/include directory? There are already automatically generated
files in there. What have you already done for stuff like
asm-arm/mach-types.h?
--
dwmw2
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 14:48 ` Keith Owens
2001-08-12 14:56 ` David Woodhouse
@ 2001-08-12 14:56 ` Russell King
2001-08-13 2:23 ` Keith Owens
1 sibling, 1 reply; 22+ messages in thread
From: Russell King @ 2001-08-12 14:56 UTC (permalink / raw)
To: Keith Owens; +Cc: David Woodhouse, kbuild-devel, linux-kernel
On Mon, Aug 13, 2001 at 12:48:14AM +1000, Keith Owens wrote:
> No. The aim is for a user to look at the makefile in a directory and
> know everything that is created in that directory. If you allow
> creation of a file in one directory but storing it in another then you
> have to search all makefiles to find out what is created in any
> directory. Horrible!
Can we have a makefile in include/asm-$(ARCH) then please?
I think stuff like:
#include "../../../../arch/arm/constants.h"
or
#include "../../../../arch/arm/tools/mach-types.h"
is even more disgusting.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-12 14:56 ` Russell King
@ 2001-08-13 2:23 ` Keith Owens
0 siblings, 0 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-13 2:23 UTC (permalink / raw)
To: Russell King; +Cc: David Woodhouse, kbuild-devel, linux-kernel
On Sun, 12 Aug 2001 15:56:33 +0100,
Russell King <rmk@arm.linux.org.uk> wrote:
>On Mon, Aug 13, 2001 at 12:48:14AM +1000, Keith Owens wrote:
>> No. The aim is for a user to look at the makefile in a directory and
>> know everything that is created in that directory. If you allow
>> creation of a file in one directory but storing it in another then you
>> have to search all makefiles to find out what is created in any
>> directory. Horrible!
>
>Can we have a makefile in include/asm-$(ARCH) then please?
>
>I think stuff like:
>
>#include "../../../../arch/arm/constants.h"
>
>or
>
>#include "../../../../arch/arm/tools/mach-types.h"
>
>is even more disgusting.
Absolutely agree, which is why there are so many FIXME comments in the
Makefile.in files, to remove all the relative includes. If a source
needs a non-standard include ioutside the current directory then it
should #include <foo.h> and the makefile should point to the directory
containing foo.h. Knowledge about non-standard include files should be
in the makefile, not embedded in lots of source code.
That still leaves the question of where the generated files should be
written to. This is getting into philosophy rather than technical, one
man's preference is another's pet hate. My preference is not to write
to any directory under include. At the moment kbuild 2.5 has a clean
separation between shipped files under /include and generated files
under arch/$(ARCH). There are only 5 generated include files and they
are only present for historical reasons.
include/linux/modversions.h
include/linux/version.h
include/linux/uts_release.h
include/linux/autoconf.h
include/linux/compile.h
Writing to include/asm is a problem for kbuild 2.5. When using
separate source and object trees, the asm-$(ARCH) symlink cannot be
created in the source tree, users may want to generate multiple
architectures from a single source tree. .tmp_include/src_000/asm is
created in the object tree, pointing at the relevant source directory
and gcc scans .tmp_include/src_000, not the source tree.
If you write to asm/foo.h then you are updating the source tree. I can
work around this by creating two sets of symlinks for include paths,
one pointing to the object directory, one to the source and telling gcc
to scan the object first. But that will make the generated commands
even longer and will slow gcc down.
My preference is to generate files in the arch subtree. The source
code does #include <foo.h> and the makefiles have lines like this
extra_aflags(entry.o -I arch/$(ARCH))
Yes, you have to add extra_aflags on every object that uses the
generated include file. But you already have to specify a dependency
from the object to the generated file to ensure that parallel make
waits until the file is generated. Doing two lines instead of one for
the affected objects is no big deal.
$(objfile entry.o): $(objfile /arch/$(ARCH)/offsets.h)
extra_aflags(entry.o -I arch/$(ARCH))
BTW, mach-types.h is going to be a problem wherever it is stored.
Several .h files include the generated file so all objects that include
these .h files are dependent on mach-types.h being generated first.
include/asm-arm/arch-ebsa285/time.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/uncompress.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/irq.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/system.h:#include <asm/mach-types.h>
include/asm-arm/arch-ebsa285/irqs.h:#include <asm/mach-types.h>
include/asm-arm/arch-arc/ide.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/uncompress.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/ide.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/irq.h:#include <asm/mach-types.h>
include/asm-arm/arch-sa1100/hardware.h:#include <asm/mach-types.h>
I do not want to reinvent make dep because of the fundamental design
problems with that approach. If any generated file depends on .config
then it must be recreated after any config changes or patches but 99.9%
of users do not do that. We must not rely on human intervention to
update kernel files, it must be automatic. This requires that make be
told the truth about the dependency graph. mach-types.h is going to
require some more work, no matter where it is stored.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Announce: Kernel Build for 2.5, Release 1.1 is available.
@ 2001-08-11 15:03 Keith Owens
2001-08-11 15:20 ` Russell King
` (4 more replies)
0 siblings, 5 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-11 15:03 UTC (permalink / raw)
To: kbuild-devel; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
Release 1.1 of kernel build for kernel 2.5 (kbuild 2.5) is available.
http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download
release 1.1.
http://marc.theaimsgroup.com/?l=linux-kernel&m=99725412902968&w=2
contains information about the base release.
Changes from Release 1.
Upgrade to kernel 2.4.8. Nice to see how simple the DRM Makefile is
now.
Correct a race when parallel building the global makefile, not all
objects were being recognised as targets and were not recognised as
candidates for recompile.
Replace hand coded rules with side_effect().
Document kbuild targets and C to assembler conversions. As always,
Documentation/kbuild/kbuild-2.5.txt is your friend.
Remove the assembler() command. kbuild now works out if the source
is .c or .S, no need for human intervention.
If you explicitly make foo.i or foo.s then kbuild automatically
generates the required rules with the same flags as the corresponding
.o file. Useful for debugging pre-processor or assembler problems,
especially when gcc -save-temps does not work with multiple
directories.
Standard generation of .s from .c files, where a .s file is required
according to make. This includes tracking the dependencies of the .c
file.
That last change lets me solve a long standing problem with kbuild 2.4.
Every architecture has Assembler that requires offsets of fields within
C structures or the mapping of C names to numbers. Assembler cannot
include the C definitions so we need a mapping from C constructs to
Assembler numbers. Every architecture has handled this problem in a
different way, none of the methods are 100% accurate nor dependable.
i386 hard codes the offsets into the assembler code and hopes that the
structure definitions never change.
Alpha uses a C program that generates the text for the assembler. This
does not work in a cross compile environment because it assumes that
HOSTCC == CC.
Cris generates a chunk of assembler from C then uses .include instead
of #include, with some fancy conditional selection.
Mips, parisc, ppc, sparc generate assembler then extract and reformat
lines from the assembler. This works in both local and cross compile
mode and is getting close to the correct way of doing it. But it still
has problems, see below.
IA64 in 2.4 is particularly loathsome. It uses different methods in
native and cross compile modes, when the cross compile version would do
for both. It ships a copy of the generated asm/offsets.h which is
totally unreliable because the real offsets.h depends on the user's
.config. To add insult to injury, offsets.h is included in processor.h
and ptrace.h on ia64 which means that it pollutes almost every C file.
None of the above methods handle dependency checking at all. PPC makes
an attempt but it is manually defined and is incomplete, no other arch
even makes an attempt. All architectures assume that the user always
runs make dep after any config changes that affect the assembler
offsets. If the user forgets to run make dep and the assembler and C
values do not match - oops.
kbuild 2.5 has a solution which works in all modes, is standard across
all architectures and automatically tracks dependency changes. No more
room for human error.
* Create arch/$(ARCH)/offsets.c containing code like this, from
arch/i386/offsets.c. This should be the standard format on all
architectures, the only difference should be the list of fields to
generate.
/*
* Generate definitions needed by assembly language modules.
* This code generates raw asm output which is post-processed to extract
* and format the required data.
*/
#include <linux/types.h>
#include <linux/stddef.h>
#include <linux/sched.h>
/* Use marker if you need to separate the values later */
#define DEFINE(sym, val, marker) \
asm volatile("\n-> " #sym " %c0 " #val " " #marker : : "i" (val))
int
main(void)
{
DEFINE(state, offsetof(struct task_struct, state),);
DEFINE(flags, offsetof(struct task_struct, flags),);
DEFINE(sigpending, offsetof(struct task_struct, sigpending),);
DEFINE(addr_limit, offsetof(struct task_struct, addr_limit),);
DEFINE(exec_domain, offsetof(struct task_struct, exec_domain),);
DEFINE(need_resched, offsetof(struct task_struct, need_resched),);
DEFINE(tsk_ptrace, offsetof(struct task_struct, ptrace),);
DEFINE(processor, offsetof(struct task_struct, processor),);
DEFINE(ENOSYS, ENOSYS,);
return 0;
}
* When that code is compiled from .c to .s using CC for the target
system, the generated Assembler contains lines like this
-> state 0 offsetof(struct task_struct, state)
-> flags 4 offsetof(struct task_struct, flags)
-> sigpending 8 offsetof(struct task_struct, sigpending)
-> addr_limit 12 offsetof(struct task_struct, addr_limit)
-> exec_domain 16 offsetof(struct task_struct, exec_domain)
-> need_resched 20 offsetof(struct task_struct, need_resched)
-> tsk_ptrace 24 offsetof(struct task_struct, ptrace)
-> processor 52 offsetof(struct task_struct, processor)
-> ENOSYS 38 ENOSYS
interspersed with Assembler declarations and blank lines.
* In arch/$(ARCH)/Makefile.in, define user commands to extract the
'->' lines from offsets.s and reformat as required for your
architecture. arch/i386/Makefile.in contains
# Convert raw asm offsets into something that can be included as
# assembler definitions. It converts
# -> symbol value source
# into
# symbol = value /* 0xvalue source */
user_command(offsets.h
($(objfile offsets.s))
(set -e;
(echo "#ifndef __ASM_OFFSETS_H__";
echo "#define __ASM_OFFSETS_H__";
awk "/^->/{
sym = \$$2;
val = \$$3;
\$$1 = \"\";
\$$2 = \"\";
\$$3 = \"\";
printf(\"%-20s = %3d\t\t\t/* 0x%x\t%s */\n\",
sym, val, val, \$$0)
}";
echo "#endif";
) < $< > $(@D).tmp_$(@F);
cmp -s $(@D).tmp_$(@F) $@ || mv $(@D).tmp_$(@F) $@
)
()
)
The awk code is a little complicated because it has to cope with both
shell (" -> \", $ -> \$) and make ($ -> $$) quoting rules but it
works, and only has to be coded once. The output from awk is written
to a .tmp_ file first, the result is compared with the previous
version (if any) and only if they are different is offsets.h updated.
The compare and update avoids spurious Assembler recompiles, most
config changes do not affect offsets.h.
The final output is in arch/$(ARCH)/offsets.h. On i386, offsets.h
contains
#ifndef __ASM_OFFSETS_H__
#define __ASM_OFFSETS_H__
state = 0 /* 0x0 offsetof(struct task_struct, state) */
flags = 4 /* 0x4 offsetof(struct task_struct, flags) */
sigpending = 8 /* 0x8 offsetof(struct task_struct, sigpending) */
addr_limit = 12 /* 0xc offsetof(struct task_struct, addr_limit) */
exec_domain = 16 /* 0x10 offsetof(struct task_struct, exec_domain) */
need_resched = 20 /* 0x14 offsetof(struct task_struct, need_resched) */
tsk_ptrace = 24 /* 0x18 offsetof(struct task_struct, ptrace) */
processor = 52 /* 0x34 offsetof(struct task_struct, processor) */
ENOSYS = 38 /* 0x26 ENOSYS */
#endif
My aim is to standardize the format of the output from offsets.s and
do any arch specific processing in the makefile. In the long run
this will be easier than having eight different ways of generating
assembler output. I have included a marker parameter in the DEFINE
macro, marker appears at the end of the '->' line, just in case an
architecture needs some indicator in order to split the offsets into
multiple files.
* Do not, under any circumstances, include offsets.h in any files that
are used by C source, offsets.h must only be used in Assembler code.
IA64 made the mistake of including offsets.h in processor.h and
ptrace.h so they have to ship the generated offsets.h to avoid C
compile errors on parallel builds. But the version that is shipped
is incorrect, it does not match the user's config, a potential source
of human error.
* Do not ship arch/$(arch)/offsets.h nor include it in any patches. Add
offsets.h to your don't diff list.
* Specify arch/$(ARCH)/offsets.h as a pre-requisite of only the objects
that need it in order to assemble. arch/i386/kernel/Makefile.in has
$(objfile entry.o): $(objfile /arch/$(ARCH)/offsets.h)
You only need to specify this dependency for the Assembler files that
use the generated offset values.
When kbuild 2.5 wants to compile entry.o, it checks if offsets.h is up
to date. user_command() says that offsets.h depends on offsets.s.
offsets.s implicitly depends on offsets.c, there is no need for an
explicit rule. Not only does offsets.s directly depend on offsets.c,
it indirectly depends on all the files included by offsets.c, either
directly or indirectly, and on all the CONFIG_ settings in offsets.c
and the included files.
If anything that affects config.s has changed it is rebuilt, the '->'
lines are extracted and, if offsets.h has changed, it is replaced.
That will force a recompile of the affected assembler objects. The
result is a standard, reliable and, above all, an automatic method of
converting C values to Assembler lines.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE7dUkji4UHNye0ZOoRAiS6AJsEyMYRmEReH09ZFThu5bf7rVPDtQCgjhAY
w+JAoVEaOASjcl+kHL34fiE=
=fuW1
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
@ 2001-08-11 15:20 ` Russell King
2001-08-11 16:03 ` Keith Owens
2001-08-11 16:08 ` Philip Blundell
2001-08-11 21:55 ` Roman Zippel
` (3 subsequent siblings)
4 siblings, 2 replies; 22+ messages in thread
From: Russell King @ 2001-08-11 15:20 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
> * Create arch/$(ARCH)/offsets.c containing code like this, from
> arch/i386/offsets.c. This should be the standard format on all
> architectures, the only difference should be the list of fields to
> generate.
I'm sorry, the ARM version of GCC does not support %c0 in a working
state. The way we generate the offsets on ARM is here to stay for
the next few years until GCC 3 has stabilised well enough for use
with the kernel, and the ARM architecture specifically.
Please don't rely on %c0 working.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:20 ` Russell King
@ 2001-08-11 16:03 ` Keith Owens
2001-08-11 16:08 ` Philip Blundell
1 sibling, 0 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-11 16:03 UTC (permalink / raw)
To: Russell King; +Cc: kbuild-devel, linux-kernel
On Sat, 11 Aug 2001 16:20:28 +0100,
Russell King <rmk@arm.linux.org.uk> wrote:
>On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
>> * Create arch/$(ARCH)/offsets.c containing code like this, from
>> arch/i386/offsets.c. This should be the standard format on all
>> architectures, the only difference should be the list of fields to
>> generate.
>
>I'm sorry, the ARM version of GCC does not support %c0 in a working
>state. The way we generate the offsets on ARM is here to stay for
>the next few years until GCC 3 has stabilised well enough for use
>with the kernel, and the ARM architecture specifically.
>
>Please don't rely on %c0 working.
If you have to use %0 instead of %c0, that is all right. Just remove
the extra '$' in the Makefile as arch/arm/tools/Makefile already does.
I would still like to see arm in 2.5 using the same style as i386,
including printing the offset in decimal and hex together with the
comment. But that is just style, the important thing is to generate
assembler offsets so that kbuild can correctly track the dependencies.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:20 ` Russell King
2001-08-11 16:03 ` Keith Owens
@ 2001-08-11 16:08 ` Philip Blundell
2001-08-11 16:14 ` Russell King
1 sibling, 1 reply; 22+ messages in thread
From: Philip Blundell @ 2001-08-11 16:08 UTC (permalink / raw)
To: Russell King; +Cc: Keith Owens, kbuild-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
>I'm sorry, the ARM version of GCC does not support %c0 in a working
>state. The way we generate the offsets on ARM is here to stay for
>the next few years until GCC 3 has stabilised well enough for use
>with the kernel, and the ARM architecture specifically.
I should think it can be made to work in 2.95.4. Did you try the patch I sent
you a few months ago?
p.
[-- Attachment #2: Type: application/pgp-signature, Size: 237 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 16:08 ` Philip Blundell
@ 2001-08-11 16:14 ` Russell King
0 siblings, 0 replies; 22+ messages in thread
From: Russell King @ 2001-08-11 16:14 UTC (permalink / raw)
To: Philip Blundell; +Cc: Keith Owens, kbuild-devel, linux-kernel
On Sat, Aug 11, 2001 at 05:08:08PM +0100, Philip Blundell wrote:
> I should think it can be made to work in 2.95.4.
Amazing response to the problem here. ;)
> Did you try the patch I sent you a few months ago?
No - I've not had a need to rebuild gcc yet, and the patch is low priority
since the kernel has to build with the compilers that people already have,
not the bleeding edge.
Sorry, I don't do gcc, as I've explained before.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
2001-08-11 15:20 ` Russell King
@ 2001-08-11 21:55 ` Roman Zippel
2001-08-12 1:17 ` Keith Owens
2001-08-12 2:24 ` Keith Owens
` (2 subsequent siblings)
4 siblings, 1 reply; 22+ messages in thread
From: Roman Zippel @ 2001-08-11 21:55 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
Hi,
Keith Owens wrote:
> None of the above methods handle dependency checking at all. PPC makes
> an attempt but it is manually defined and is incomplete, no other arch
> even makes an attempt.
I'm wondering that you don't mention m68k, because we generate
dependencies...
(Has nothing to do with kbuild, I'm just curious. :) )
bye, Roman
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 21:55 ` Roman Zippel
@ 2001-08-12 1:17 ` Keith Owens
0 siblings, 0 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 1:17 UTC (permalink / raw)
To: Roman Zippel; +Cc: kbuild-devel, linux-kernel
On Sat, 11 Aug 2001 23:55:04 +0200,
Roman Zippel <zippel@linux-m68k.org> wrote:
>Keith Owens wrote:
>
>> None of the above methods handle dependency checking at all. PPC makes
>> an attempt but it is manually defined and is incomplete, no other arch
>> even makes an attempt.
>
>I'm wondering that you don't mention m68k, because we generate
>dependencies...
>(Has nothing to do with kbuild, I'm just curious. :) )
Because I did a quick sweep through the arch makefiles looking for the
word 'offsets'. That is part of the problem, the offsets file has
different names in some architectures. Most call it offsets, PPC uses
mk_def and ppc_defs, arm uses getconstants and constants, m68k uses
m68k_defs. It does not help when the code that generates the asm
constants is in different directories on some architectures.
Now you know why I want a standard method, with a standard name and
standard directory location.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
2001-08-11 15:20 ` Russell King
2001-08-11 21:55 ` Roman Zippel
@ 2001-08-12 2:24 ` Keith Owens
2001-08-12 4:30 ` Keith Owens
2001-08-19 7:13 ` Richard Henderson
4 siblings, 0 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 2:24 UTC (permalink / raw)
To: kbuild-devel, linux-kernel
Bug fixes against 2.4.8 + kbuild-2.5-2.4.8-1. I will put up a -2 later
today.
Index: 8.7/drivers/sound/emu10k1/Makefile.in
--- 8.7/drivers/sound/emu10k1/Makefile.in Sat, 11 Aug 2001 22:55:17 +1000 kaos (linux-2.4/G/d/38_Makefile.i 1.2 644)
+++ 8.7(w)/drivers/sound/emu10k1/Makefile.in Sun, 12 Aug 2001 12:21:44 +1000 kaos (linux-2.4/G/d/38_Makefile.i 1.2 644)
@@ -3,8 +3,9 @@
#
# 12 Apr 2000 Rui Sousa
-objlink(emu10k1.o efxmgr.o emuadxmg.o hwaccess.o irqmgr.o joystick.o main.o
- midi.o mixer.o passthrough.o recmgr.o timer.o voicemgr.o)
+objlink(emu10k1.o audio.o cardmi.o cardmo.o cardwi.o cardwo.o ecard.o efxmgr.o
+ emuadxmg.o hwaccess.o irqmgr.o joystick.o main.o midi.o mixer.o
+ passthrough.o recmgr.o timer.o voicemgr.o)
select(CONFIG_SOUND_EMU10K1 emu10k1.o)
Index: 8.7/scripts/pp_makefile2.c
--- 8.7/scripts/pp_makefile2.c Sat, 11 Aug 2001 22:45:22 +1000 kaos (linux-2.4/I/d/36_pp_makefil 1.24 644)
+++ 8.7(w)/scripts/pp_makefile2.c Sun, 12 Aug 2001 11:43:58 +1000 kaos (linux-2.4/I/d/36_pp_makefil 1.24 644)
@@ -754,7 +754,10 @@ int special_oais(PP_DIRENT *dirent, PP_D
}
if (dirent->value.db) {
DB *db = db_list[dirent->value.db];
- if (!dirent->istarget) {
+ /* FIXME: when the go faster stripes are added, make sure that
+ * dirent->istarget and db->istarget are synced earlier.
+ */
+ if (!db->istarget && !dirent->istarget) {
return(0);
}
switch (type) {
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
` (2 preceding siblings ...)
2001-08-12 2:24 ` Keith Owens
@ 2001-08-12 4:30 ` Keith Owens
2001-08-19 7:13 ` Richard Henderson
4 siblings, 0 replies; 22+ messages in thread
From: Keith Owens @ 2001-08-12 4:30 UTC (permalink / raw)
To: kbuild-devel; +Cc: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-Type: text/plain; charset=us-ascii
I have replaced kbuild-2.5-2.4.8-1.bz2 with 2.5-2.4.8-2.bz2 under
http://sourceforge.net/projects/kbuild/, Package kbuild-2.5, download
release 1.1. The patch is against a clean 2.4.8 kernel.
Changes from -1.
Update emu10k1/Makefile.in to the full 2.4.8 list of objects.
Correct a bug that dropped some objects from the build list.
Rework the generation of assembler offsets from C. It uses %0
instead of %c0, RMK says that %c0 does not work reliably on arm. The
sample awk code handles %0 and has been cleaned up. The output to a
.tmp file followed by compare has been removed, it caused problems
for make install. More documentation, including settings for include
files.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999
iD8DBQE7dgZOi4UHNye0ZOoRAj/rAJ48whc56FMuUpf9SIu4n/lwx8XUGACfcT6S
Q34ZBrZfXQKJPjzbyTAQ+g0=
=rAh+
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: Announce: Kernel Build for 2.5, Release 1.1 is available.
2001-08-11 15:03 Keith Owens
` (3 preceding siblings ...)
2001-08-12 4:30 ` Keith Owens
@ 2001-08-19 7:13 ` Richard Henderson
4 siblings, 0 replies; 22+ messages in thread
From: Richard Henderson @ 2001-08-19 7:13 UTC (permalink / raw)
To: Keith Owens; +Cc: kbuild-devel, linux-kernel
On Sun, Aug 12, 2001 at 01:03:00AM +1000, Keith Owens wrote:
> asm volatile("\n-> " #sym " %c0 " #val " " #marker : : "i" (val))
This is bad -- 'c' requests an address constant (CONSTANT_ADDRESS_P
if you're playing from home), and as defined this constant must be
valid in an instruction.
Such things are by nature target specific. On ia64, for instance,
there are *no* valid address constants, since all valid memory
addresses are simple registers.
You can do what you want here with just "%0".
r~
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2001-08-19 7:28 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20010811212051.A819@jaquet.dk>
2001-08-12 2:11 ` Announce: Kernel Build for 2.5, Release 1.1 is available Keith Owens
2001-08-12 2:27 ` Tom Rini
2001-08-12 7:31 ` [kbuild-devel] " Rasmus Andersen
2001-08-12 7:44 ` Keith Owens
2001-08-12 7:57 ` Daniel T. Chen
2001-08-11 22:02 [kbuild-devel] " Tom Rini
2001-08-12 1:21 ` Keith Owens
2001-08-12 1:44 ` Tom Rini
2001-08-12 14:36 ` David Woodhouse
2001-08-12 14:48 ` Keith Owens
2001-08-12 14:56 ` David Woodhouse
2001-08-12 14:56 ` Russell King
2001-08-13 2:23 ` Keith Owens
-- strict thread matches above, loose matches on Subject: below --
2001-08-11 15:03 Keith Owens
2001-08-11 15:20 ` Russell King
2001-08-11 16:03 ` Keith Owens
2001-08-11 16:08 ` Philip Blundell
2001-08-11 16:14 ` Russell King
2001-08-11 21:55 ` Roman Zippel
2001-08-12 1:17 ` Keith Owens
2001-08-12 2:24 ` Keith Owens
2001-08-12 4:30 ` Keith Owens
2001-08-19 7:13 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox