[kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Content-Type: text/plain; charset=us-ascii On Fri, 28 Dec 2001 13:31:42 +1100, Keith Owens <[EMAIL PROTECTED]> wrote: >This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. >Patches for other architectures and kernels will be out later today, it >takes time to generate and test patches for 6 architectures against 3 >different kernel trees. All architecture and tree specific patches for kbuild 2.5 are now available, if you don't see your arch then nobody has sent me a patch yet. kbuild-2.5-2.4.16-3 Base code and i386. Use this patch for 2.5.0 as well. kbuild-2.5-2.4.17-1 From 2.4.16 to 2.4.17. kbuild-2.5-2.4.18-pre1-1From 2.4.17 to 2.4.18-pre1. kbuild-2.5-2.5.1-1 From 2.4.16 (2.5.0) to 2.5.1. kbuild-2.5-2.5.2-pre3-1 From 2.5.1 to 2.5.2-pre3. kbuild-2.5-2.4.16-alpha-1 Add on for alpha by Ghozlane Toumi. kbuild-2.5-2.4.16-ppc-1 Add on for ppc by Tom Rini. kbuild-2.5-2.4.17-ia64-011226-1 Add on for ia64-011226, only for 2.4.17. kbuild-2.5-2.4.16-sparc32-2 Add on for sparc32, Ben Collins, Keith Owens. kbuild-2.5-2.4.16-sparc64-2 Add on for sparc64, Ben Collins, Keith Owens. Everybody needs kbuild-2.5-2.4.16-3. Fetch the other patches if you want other kernels or architectures. Alpha and PPC do not have CML2 support yet, everything else has CML2 support. PPC does not have bzImage support yet. - --- One script to rule them all, One script to find them, One script to bring them all and in the darkness build them. In the land of Linux, using shadow trees. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE8LX6Di4UHNye0ZOoRAk8gAKC8dGevkBebzYSgM1abvTEh3HyxIACgttJH a1gwFid6KpDBTH7kGmZ1kf0= =OCPO -END PGP SIGNATURE- ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
"Eric S. Raymond" wrote: > > Linus Torvalds <[EMAIL PROTECTED]>: > > Eric, this is the _wrong_approach_. I want /local/ files, not global ones. > > First: where should the prompt-string definitions for capability > symbols that occur in multiple port trees live? Proposal: the main cml script in linux root dir should be as little as possible. it will include all the arch/*/ cml files (for really specifific options) and you move other item into the subdir drivers/ (the natural place, all file who should not be in driver/ are by definition arch specific). > > Second: Forward references, and references across the tree, mean that > there is a class of symbols that have theoretically natural home directories > but which would have to be declared elsewhere in order to be defined at > the point of first reference. > > (A potential solution to this would be to improve the CML2 compiler's > handling of forward references.) No. CML2 could be improved to handle che forward references, but not user that will use line config. > Third: I could hack my installer to break Configure.help up into > a bunch of little component CML files distributed through the tree... > but Configure.help doesn't currently contain any markup that says > where to direct each entry to. The Makefile should help you. > Fourth: There's still the localization issue. If it's your ukase > that this is not an important problem, then I'll accept that -- but > I haven't heard you say that yet, so I'm not sure you've considered > it enough. PROPOSAL: You add a tool to build a big file from the sparse symbols.cml. Translator will use this file as references, adn your CML2 will use translated big files or the default sparse little files. This should not be a problem, because a translator will read documentation (unlike the most user), so you can explain how to do this work. (And the 'diff' could be a friend to the translators). kbuild-2.5 have already support for 'clean' driver (clean: driver that don't touch existing files). I like it. If CML2 could handle natively also these change it would great. The problem is the use of multiple sources dir. I think you and Keith should coordinate this work. And I find clean if also configuration files go into makefiles. giacomo PS: Keith: How you handle the obsolete files? (foo.c in the main source. the patch in source src1 will remove this file). Actually I have create a shell script kpatch: a new implementation of scripts/patch-kernel, that handles normal, testing and testing/incr patches, dont-use patches, multiple sources and new (and clean) destination dir). ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
Hi, > Taking nothing away from Tridge, I like Tridge, I'd like to see numbers. > I'm sure that Tridge's stuff is great, but we were very motivated to > go well beyond the normal effort when we wrote this code. How large is your core db stuff? The thing I like about tdb is that it is very simple, only recently growing over 1024 lines. Anton ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
On Fri, 28 Dec 2001, Linus Torvalds wrote: > Having per-function comment blocks, in contrast, makes sense to have > inline: > > - you read the comment when you read the function > - you might even update the comment when you update the function > - you have a reasonable 1:1 relationship. Personally I'd like to see each C file have a header like this too, describing in a few lines what the functions in this file are supposed to do. This should make it easier for people to figure out not just what each C file is about, but also if they should spend their time wading through this particular C file when in search of some piece of code. regards, Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
On Sat, 29 Dec 2001, Keith Owens wrote: > ps. I don't want mail discussing individual bug fixes to mkdep. Code > that does not fix _all_ 9 bugs listed in makefile-2.5_make_dep.html > is pointless. I guess you presented a good point to not ignore bug number 10 (the speed one) either. ;) Rik -- Shortwave goes a long way: irc.starchat.net #swl http://www.surriel.com/ http://distro.conectiva.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] kpatch.sh
Hello. I just created 'kpatch.sh'. This bash shell apply automatically multiple kernel patches. script/patch-kernel already exists in current kernels, but it has some limit, which I would eliminate. WARNING: It is in early beta stage: I made very few tests. My scripts: - support all official kernel releases (x.y.z plain releases, -pre and -rc releases) support means: it can start from any official kernel and it can stop to any other official kernel (with the restrictions: only upgrade, and only within the same kernel serie or from 2.4 to 2.5, and only if patches exists), using normal patches and/or the testing patches and/or incremental teesting patches. It knows also the suffix 'dont-use'. - the patches can be in multiple directories - the sources can be in multiple directories - destination directory can be a different (and empty new) directory The last features, used with the kbuild-2.5 allow to have the plain source and some pre releases (or also other release) sharing the most of sources. [Maybe this will incraese the testing people] TODO: - Better serie crossing (not really necessary, the infrastructure in already done, but AFAIK Linus will change the transitions name every new stable release) (easy) - The 'kbuild-2.5' patch I uncompress and read the patches twice. It is possible to read and feed to patch line per line. (easy? bash engeenering) - Support of -ac, -dj and other -xx patches. (infrastructure already done, also for ev. incremental patches) (very easy) - Reading the sources and destination dirs from the kbuild-2.5 environment variable (easy) - downloading from net latest patches (downloading is not std unix operation, anyway quite easy with wget) - Creating needed incremental patches with interdiff (e.g. I have X.16, X.17-pre5, X.17, and I'm in X.17-pre5) (easy) - The above problem can be solved using reversed patch. But in this case can happend that I should reverse several incremental patches. (medium: rewrite of some functions for downgrading) Usage: (Read also the bottom of the script) --source=dir Add the to the list of sources dirs --patch=dir Add the to the list of patches dirs --dest=dir set the destination directory. this option set the 'kbuild-2.5 patch mode' --testing Go to the last testing version (instead of last full version) --dry-run Print only the patches to be applied, but don't patch --until=ver Apply patch until the . Default: the last possible release within the same serie can be also the serie kernel name(2.4/2.5). This means: the last possible release of the serie Other arguments: If it is a dir and have Makefile or A_version: alias of --source= else if it is a dir: alias of --patch= else alias of --last= The script is in: people.debian.org/~cate/files/misc/kbuild.sh giacomo ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
On Sat, Dec 29, 2001 at 08:24:37PM +1100, Anton Blanchard wrote: > How large is your core db stuff? The thing I like about tdb is that it > is very simple, only recently growing over 1024 lines. 14044736 32921 mdbm.c -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
On Fri, 28 Dec 2001, Legacy Fishtank wrote: > > A per-driver metadata file is IMHO clearly the preferred solution. Note that it doesn't need to be per-driver: there are good reasons to have "combined" files too. For example, things like "architecture config" could all be in one file, along with similar drivers (ie "3com network devices", whatever). Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config & build system
On Sat, 29 Dec 2001, Keith Owens wrote: > > Yes, some of the problems with mkdep can be fixed in the current design > but there is one problem that is inherently unfixable. make dep is a > manual process so it relies on users knowing when they have to rerun > make dep AND THEY DON'T DO IT! Don't be silly. Make the dependency file itself depend on all the files it describes, and add a makefile rule to re-generate it. Poof, problem gone. > Dependencies _do_ change when your .config changes, Only if you do them wrong. Look at mkdep.c - it statically determines the complete list of header files that _can_ be included, and does not care at all about what config options there are. > that are included varies. gcc -MD gets this exactly right, gcc knows > which files it read. Bzzt, it knows the subset of files to read, nothing more. Linus ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
On Fri, Dec 28, 2001 at 05:31:51PM -0500, Eric S. Raymond wrote: > When I talk about "rules that use architecture symbols to suppress > things like bus types" I have in mind things like this: [snip] > unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? > unless PCI suppress dependent USB HOTPLUG_PCI And there's hope this will die soon too (USB) ... > unless (X86 or ALPHA or MIPS32 or PPC) suppress usb or SPARC or SPARC64 (iirc) or ARM (once !pci usb is allowed)... > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent >IEEE1394 Wouldn't the experimental be global? And maybe the PCI too? > It seems to me *extremely* unlikely that a typical patch from a PPC maintainer > would mess with any of these! They're rules that are likely to be written > once at the time a new port is added to the tree and seldom or ever changed > afterwards. But they will be modified for new arch X, or when constraint X (like PCI) is removed. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
On Sat, Dec 29, 2001 at 07:27:51PM +1100, Keith Owens wrote: > Content-Type: text/plain; charset=us-ascii > > On Fri, 28 Dec 2001 13:31:42 +1100, > Keith Owens <[EMAIL PROTECTED]> wrote: > >This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. > >Patches for other architectures and kernels will be out later today, it > >takes time to generate and test patches for 6 architectures against 3 > >different kernel trees. > > All architecture and tree specific patches for kbuild 2.5 are now > available, if you don't see your arch then nobody has sent me a patch > yet. [snip] > kbuild-2.5-2.4.16-ppc-1 Add on for ppc by Tom Rini. This seems to have been generated (or applied originally) w/ the wrong -p level (I suspect 'cuz of the wierd way I created the diff tho), since this creates ./ppc/.., instead of ./arch/ppc/... -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
Tom Rini <[EMAIL PROTECTED]>: > > unless (ISA or PCI) suppress dependent IDE > > Just a minor point, but what about non-PCI/ISA ide? The CML1 rules seem to imply that this set is empty. > > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent >IEEE1394 > > Wouldn't the experimental be global? And maybe the PCI too? I don't understand what change you are suggesting. > > It seems to me *extremely* unlikely that a typical patch from a PPC > > maintainer would mess with any of these! They're rules that are likely to > > be written once at the time a new port is added to the tree and seldom or > > ever changed afterwards. > > But they will be modified for new arch X, or when constraint X (like > PCI) is removed. Yes. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond "Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient...The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding." -- Supreme Court Justice Louis Brandeis ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > > unless (ISA or PCI) suppress dependent IDE > > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. It's not. In fact, I don't really see that implication either. There's lots of drivers hidden under a CONFIG_PCI check, but nothing under an ISA check. From ~line 104 to ~136 I suspect are all non-PCI and non-ISA chipsets. > > > unless (X86 and PCI and EXPERIMENTAL) or PPC or ARM or SPARC suppress dependent >IEEE1394 > > > > Wouldn't the experimental be global? And maybe the PCI too? > > I don't understand what change you are suggesting. unless EXPERIMENTAL and (((X86 or PPC or SPARC) and PCI) or ARM) Since the experimental tag I believe would be a global thing, and I'm thinking that ARM probably implies !PCI (since it does so often, but I don't know for sure..). > > > It seems to me *extremely* unlikely that a typical patch from a PPC > > > maintainer would mess with any of these! They're rules that are likely to > > > be written once at the time a new port is added to the tree and seldom or > > > ever changed afterwards. > > > > But they will be modified for new arch X, or when constraint X (like > > PCI) is removed. > > Yes. Not typical than, but it could/will happen, from arch maintainer Y. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
On Sat, Dec 29, 2001 at 03:27:06PM -0700, Tom Rini wrote: > On Sat, Dec 29, 2001 at 07:27:51PM +1100, Keith Owens wrote: > > Content-Type: text/plain; charset=us-ascii > > > > On Fri, 28 Dec 2001 13:31:42 +1100, > > Keith Owens <[EMAIL PROTECTED]> wrote: > > >This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. > > >Patches for other architectures and kernels will be out later today, it > > >takes time to generate and test patches for 6 architectures against 3 > > >different kernel trees. > > > > All architecture and tree specific patches for kbuild 2.5 are now > > available, if you don't see your arch then nobody has sent me a patch > > yet. > [snip] > > kbuild-2.5-2.4.16-ppc-1 Add on for ppc by Tom Rini. > > This seems to have been generated (or applied originally) w/ the wrong > -p level (I suspect 'cuz of the wierd way I created the diff tho), since > this creates ./ppc/.., instead of ./arch/ppc/... And now more importantly, here's a patch to gets everything right. This is vs 2.4.16 + kbuild-2.5-2.4.16-3 + kbuild-2.5-2.4.16-ppc-1 (after making it apply correctly). I'll be sending along a 2.4.18-pre1 patch later on (but vs a different base tree for now). This fixes 3 things: 1) Add -Wa,-m405 to CONFIG_4xx AFLAGS 2) Either include or "ppc_defs.h". 3) Only have include if we're !__ASSEMBLY__, since we were getting a warning. I mean to spend a bit more time poking around and seeing what/when we should/shouldn't be defining STACK_FRAME_OVERHEAD, but for now this should do it. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ = arch/ppc/Makefile.defs.config 1.1 vs edited = --- 1.1/arch/ppc/Makefile.defs.config Sat Dec 29 00:47:34 2001 +++ edited/arch/ppc/Makefile.defs.configSat Dec 29 16:36:17 2001 @@ -16,15 +16,16 @@ # We can have any number of 'head.o' files, depending on CPU. # So we go ahead and set a default one and then modify it (and # CFLAGS) based on what processor we're on. arch_head = arch/ppc/kernel/head.o ifneq ($(subst n,,$(CONFIG_4xx)),) CFLAGS += -Wa,-m405 + AFLAGS += -Wa,-m405 arch_head := arch/ppc/kernel/head_4xx.o endif ifneq ($(subst n,,$(CONFIG_8xx)),) arch_head := arch/ppc/kernel/head_8xx.o endif ifneq ($(subst n,,$(CONFIG_PPC64BRIDGE)),) = arch/ppc/kernel/ppc_asm.h 1.19 vs edited = --- 1.19/arch/ppc/kernel/ppc_asm.h Sun Nov 4 04:58:20 2001 +++ edited/arch/ppc/kernel/ppc_asm.hSat Dec 29 16:36:47 2001 @@ -17,7 +17,11 @@ #include #include "ppc_asm.tmpl" +#ifdef CONFIG_KBUILD_2_5 +#include +#else #include "ppc_defs.h" +#endif /* * Macros for storing registers into and loading registers from = include/asm-ppc/processor.h 1.32 vs edited = --- 1.32/include/asm-ppc/processor.hSun Oct 7 17:32:53 2001 +++ edited/include/asm-ppc/processor.h Sat Dec 29 16:50:31 2001 @@ -13,7 +13,6 @@ #include -#include #include #include @@ -536,6 +535,8 @@ #define SR15 15 #ifndef __ASSEMBLY__ +/* Avoid a warning when we're included with */ +#include #if defined(CONFIG_ALL_PPC) extern int _machine; ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > > unless (ISA or PCI) suppress dependent IDE > > > > Just a minor point, but what about non-PCI/ISA ide? > > The CML1 rules seem to imply that this set is empty. RiscPC: CONFIG_PCI=n CONFIG_ISA=n CONFIG_ARCH_ACORN=y Yet, we have in drivers/ide: if [ "$CONFIG_ARCH_ACORN" = "y" ]; then dep_bool 'ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE $CONFIG_ARCH_ACORN dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS $CONFIG_BLK_DEV_IDE_ICSIDE dep_bool 'Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO $CONFIG_BLK_DEV_IDEDMA_ICS define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS dep_bool 'RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE $CONFIG_ARCH_ACORN fi So I guess I've found a bug. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: State of the new config & build system
Russell King <[EMAIL PROTECTED]>: > On Sat, Dec 29, 2001 at 05:43:54PM -0500, Eric S. Raymond wrote: > > Tom Rini <[EMAIL PROTECTED]>: > > > > unless (ISA or PCI) suppress dependent IDE > > > > > > Just a minor point, but what about non-PCI/ISA ide? > > > > The CML1 rules seem to imply that this set is empty. > > RiscPC: > CONFIG_PCI=n > CONFIG_ISA=n > CONFIG_ARCH_ACORN=y > > Yet, we have in drivers/ide: > if [ "$CONFIG_ARCH_ACORN" = "y" ]; then > dep_bool 'ICS IDE interface support' CONFIG_BLK_DEV_IDE_ICSIDE >$CONFIG_ARCH_ACORN > dep_bool ' ICS DMA support' CONFIG_BLK_DEV_IDEDMA_ICS >$CONFIG_BLK_DEV_IDE_ICSIDE > dep_bool 'Use ICS DMA by default' CONFIG_IDEDMA_ICS_AUTO >$CONFIG_BLK_DEV_IDEDMA_ICS > define_bool CONFIG_BLK_DEV_IDEDMA $CONFIG_BLK_DEV_IDEDMA_ICS > dep_bool 'RapIDE interface support' CONFIG_BLK_DEV_IDE_RAPIDE >$CONFIG_ARCH_ACORN > fi > > So I guess I've found a bug. I have removed the constraint in question. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Let us hope our weapons are never needed --but do not forget what the common people knew when they demanded the Bill of Rights: An armed citizenry is the first defense, the best defense, and the final defense against tyranny. If guns are outlawed, only the government will have guns. Only the police, the secret police, the military, the hired servants of our rulers. Only the government -- and a few outlaws. I intend to be among the outlaws. -- Edward Abbey, "Abbey's Road", 1979 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] CNL2-1.9.17 is available.
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 1.9.17: Sat Dec 29 19:08:06 EST 2001 * Minor rulebase fixes from lkml. * Fixed the last reported of Richard Todd's edge cases. * Nailed a lurking compiler bug that prevented < and > from being handled properly. * James Mayer's fix for trit comparison. The bug queue is empty. -- http://www.tuxedo.org/~esr/";>Eric S. Raymond Sometimes it is said that man cannot be trusted with the government of himself. Can he, then, be trusted with the government of others? -- Thomas Jefferson, in his 1801 inaugural address ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 1.12 is available
On Sat, Dec 29, 2001 at 07:27:51PM +1100, Keith Owens wrote: > Content-Type: text/plain; charset=us-ascii > > On Fri, 28 Dec 2001 13:31:42 +1100, > Keith Owens <[EMAIL PROTECTED]> wrote: > >This announcement is for the base kbuild 2.5 code, i386 against 2.4.16. > >Patches for other architectures and kernels will be out later today, it > >takes time to generate and test patches for 6 architectures against 3 > >different kernel trees. > > All architecture and tree specific patches for kbuild 2.5 are now > available, if you don't see your arch then nobody has sent me a patch > yet. > > kbuild-2.5-2.4.16-3 Base code and i386. Use this patch for > 2.5.0 as well. > kbuild-2.5-2.4.17-1 From 2.4.16 to 2.4.17. > kbuild-2.5-2.4.18-pre1-1 From 2.4.17 to 2.4.18-pre1. Okay, here's the patch for PPC for 2.4.18-pre1. I didn't try, but I suspect that 2.4.17 will work w/o any additional patches. This patch relies on 2.4.16-3, 2.4.16-ppc-1, the patch I sent out prior for 2.4.16, 2.4.17-1 and 2.4.18-pre1-1. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ = arch/ppc/kernel/Makefile.in 1.1 vs edited = --- 1.1/arch/ppc/kernel/Makefile.in Sat Dec 29 00:47:34 2001 +++ edited/arch/ppc/kernel/Makefile.in Sat Dec 29 17:52:00 2001 @@ -19,10 +19,9 @@ select(CONFIG_WALNUT walnut_setup.o) select(CONFIG_WALNUT CONFIG_PCI galaxy_pci.o) select(CONFIG_6xx l2cr.o) -select(CONFIG_ALL_PPC pmac_pic.o pmac_setup.o pmac_time.o prom.o feature.o - pmac_pci.o chrp_setup.o chrp_time.o chrp_pci.o open_pic.o - indirect_pci.o i8259.o prep_pci.o prep_time.o prep_nvram.o - prep_setup.o) +select(CONFIG_ALL_PPC pmac_pic.o pmac_setup.o pmac_time.o prom.o pmac_feature.o + pmac_pci.o chrp_setup.o chrp_time.o chrp_pci.o open_pic.o i8259.o + indirect_pci.o prep_pci.o prep_time.o prep_nvram.o prep_setup.o) select(CONFIG_ALL_PPC CONFIG_SMP pmac_smp.o chrp_smp.o) select(CONFIG_BOOTX_TEXT btext.o) select(CONFIG_NVRAM pmac_nvram.o) ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
