Re: [kbuild-devel] help patch: clarification in BLK_DEV_IDEDMA_PCI
On Mon, Nov 25, 2002 at 05:02:46PM +0100, Ralf Stephan wrote: Kernel: 2.4.19 Summary: wording in BLK_DEV_IDEDMA_PCI help text is misleading. Symptom: text contains no hint about Pmacs needing this option whenever BLK_DEV_IDEDMA_PMAC is selected leading to unresolved symbols at the final link. Been there done that... Reasons: BLK_DEV_IDEDMA_PMAC code depends on BLK_DEV_IDEDMA_PCI code. The text as it is talks only about Pentium systems. Proposed solutions: --- 1. the patch below, or, [snip a patch mentioning that powerpmac + PCI == enable this] 2. pull the IDEDMA_PMAC options under BLK_DEV_IDEDMA_PCI so that it is impossible to select BLK_DEV_IDEDMA_PMAC without BLK_DEV_IDEDMA_PCI. IMHO anyhow, 2 is the most correct. Paul? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] Have split-include take another argument
On Thu, Nov 14, 2002 at 03:01:18PM -0600, Kai Germaschewski wrote: On Mon, 11 Nov 2002, Tom Rini wrote: Hello. The following patch makes split-include take another argument, which is the prefix of what is being split up. This is needed since I'm working on a system which will allow for various params in the kernel to be tweaked at compile-time, without offering numerous CONFIG options (see http://marc.theaimsgroup.com/?l=linux-kernelm=103669658505842w=2). I'm sending this out for two reasons. First, does anyone see any problems with the patch itself? Second, Kai, would you be willing to apply this patch now, or would should I wait until the system is ready? Hmmh, I think I'd rather like to wait for the rest of the patch to see what its actual purpose is. If at all possible, I'd like to avoid introducing further hacks like this into kbuild, but that's more easily discussed when I can see what you're trying to achieve. Okay. I hope to have another version of the patch out soon, and with a few more kbuild questions once I convince myself that most of it works (Adding in something similar to the CONFIG tweaking done by fixdep, but with no real convinient way to see if the user changed something or not). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux kernel conf 1.2
On Wed, Oct 30, 2002 at 02:58:41AM +0100, Roman Zippel wrote: Hi, Tom Rini wrote: How would I do this with the new syntax, other than: config FTR_A bool depends on BOARD_A || BOARD_B default y ... The desire is to be able to add in support for a new platform, without having to rely on much context to patch (or, have a file be automagically included. You can do this: config FTR_A bool default y if BOARD_A ... config FTR_A bool default y if BOARD_B lkc takes the first default where the dependency is different from 'n', so the result is basically the same as BOARD_A || BOARD_B. BTW the type definition is also only needed once (it only must be the same everywhere). Does that would you need? I think that will do. So I can do something like: config BOARD_A bool Board A help ... config BOARD_B bool Board B help ... config FTR_A bool default y if BOARD_A config FTR_B bool default y if BOARD_A config FTR_A default y if BOARD_B ? Now, can that be done any smaller? (one line, after it's defined once) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux kernel conf 1.2
On Wed, Oct 30, 2002 at 03:47:56AM +0100, Roman Zippel wrote: Hi, On Tue, 29 Oct 2002, Tom Rini wrote: Now, can that be done any smaller? (one line, after it's defined once) Even smaller? What do you mean? Well, less lines. Is: config FTR_A bool default y if BOARD_A legal ? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, Aug 12, 2002 at 09:45:37PM +0200, Roman Zippel wrote: More examples of the cml1 limitations can be found in arch/ppc/config.in - a single choice statement needs to be splitted into multiple choice statements. Er, which are you referring to here? All of the choice statements are done for clarity here. :) Tho I was (and have been) pondering creating arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all of the options related to IBM 4xx processors to one file, Motorola 8xx to another, and general PPC's nicely. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 12:13:51AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: More examples of the cml1 limitations can be found in arch/ppc/config.in - a single choice statement needs to be splitted into multiple choice statements. Er, which are you referring to here? All of the choice statements are done for clarity here. :) Tho I was (and have been) pondering creating arch/ppc/platforms/Config-[468]xx.in, which would rather nicely move all of the options related to IBM 4xx processors to one file, Motorola 8xx to another, and general PPC's nicely. There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. Er, 'general machine type' ? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 12:32:50AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: There is still a bit of overlap. Roughly it's possible to sort the machine types by cpu type, but IMO it's not the best solution. I think it would be better to sort them by general machine type. Er, 'general machine type' ? +-RPX | +- ... +-TQM | +- ... +-Motorola | +- ... ... A bit more flexibility certainly wouldn't hurt. :) What does that gain however? And it wouldn't make as much sense to offer the IBM Spruce (750) next to the IBM Walnut (405GP). So in short, the various choice menus in arch/ppc/config.in aren't to work around CML1 issues, it an intentional design (which really needs to become 4 files). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 01:17:15AM +0200, Roman Zippel wrote: Hi, On Mon, 12 Aug 2002, Tom Rini wrote: A bit more flexibility certainly wouldn't hurt. :) What does that gain however? And it wouldn't make as much sense to offer the IBM Spruce (750) next to the IBM Walnut (405GP). You weren't forced to sort them by cpu type. Maybe it works as is, you should know that better than me. heh. It is something actually works pretty well, and with the rare exception of things which can show up twice (see below) it's rather logical too. I only used it as an example, because my tool has problems to automatically convert this construct into something useful (e.g. because of CONFIG_WILLOW in 2 seperate choice statements). That's because CONFIG_WILLOW can either have an 8260 CPU or a 7xx/74xx CPU. Or I think an ARM cpu... And unfortunatly I don't think support for anything beyond maybe 8260 is actually in the trees right now anyhow. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] PATCH 2.5: kconfig synchronise banners 3
On Sun, Jun 30, 2002 at 08:15:55PM +1000, Greg Banks wrote: G'day, 1/3 definitions of CONFIG_BLK_DEV_FD have trivially different banners. [Rusty: this is the one davem didn't like, rejigged to remove PC from one case instead of add it to the other 2]. Ick. How about we just keep the banners different? The 'normal' floppy disk driver for one arch/machine might not be controlled by CONFIG_BLK_DEV_FD. (eg, the 'normal' floppy driver for a pmac isn't, and on PPC we have a config that runs on machines with a PC floppy driver and with a pmac-specific one). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] kbuild PowerPC port
On Tue, Apr 09, 2002 at 01:21:03PM +1000, Keith Owens wrote: On Tue, 09 Apr 2002 12:43:07 +1000, Brendan J Simon [EMAIL PROTECTED] wrote: Anyone working on the PowerPC ports for Kbuild-2.5 release 2 ?? I will be asking the arch maintainers to do kbuild 2.5 patches for their architecture, after I have done ia64 to make sure there are no arch dependent funnies luring about. In most cases, the arch dependent patches from release 1.12 should work just as well, I rewrote the core logic but barely changed the makefiles. It's on my to-do list, but probably only for 2.5 kernels. And it'll be a quick BE test of the v2.0 stuffs :) -- 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] 2048 max variables in xconfig?
On Sun, Jan 20, 2002 at 10:22:42AM +1100, Keith Owens wrote: On Sat, 19 Jan 2002 12:39:16 -0700, Tom Rini [EMAIL PROTECTED] wrote: Hey all. I've just run into a situation where xconfig won't run because there's 2048 variables for it to deal with. If I'm reading the source right, I should just be able to bump VARTABLE_SIZE in scripts/tkparse.c and everything should just work (and from my quick testing, it does). But I figured I'd check with more knowledgeable people, so is this right? Thanks. No good reason to make vartable a fixed size. This makes it dynamic and removes the limit problem. Added to my kbuild-2.5 tree, along with Bernd Petrovitsch's patch for mouse wheel. Okay. Some bad news is that this breaks running xconfig on a Solaris host. I'm trying to get gdb on the system so I can try and debug it. Any ideas tho? -- 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] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: Eric S. Raymond wrote: kbuild team members: Dirk Hohndel has volunteered to have a chat with Linus about the CML2/kbuild-2.5 transition (and, implicitly, the status and role of the kbuild team). Please inform him of: 1) your technical judgement and opinions about CML2 and kbuild-2.5 2) the problems with the present build system, 3) whether or not you think CML2 and kbuild-2.5 should be mainstreamed into the kernel, 4) known remaining problems with CML2 and kbuild-2.5, and what the plans are to address them. He needs to hear from the whole kbuild team and properly understand the background of our present rather frustrating situation. [snip] CML2: [snip] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. Right now symbols without a help entry still won't show up unless CONFIG_ADVANCED is set (right?). And as a case in point (which I told Eric not to do), CONFIG_PPC_RTC is currently a derived symbol instead of being a question (and if I read the derivation right, it's wrong to boot). -- 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] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 10:51:18AM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: Right now symbols without a help entry still won't show up unless CONFIG_ADVANCED is set (right?). And as a case in point (which I told Eric not to do), CONFIG_PPC_RTC is currently a derived symbol instead of being a question (and if I read the derivation right, it's wrong to boot). I must have missed some mail from you. If it's still incorrect in 2.3.0, I will fix it. I could have sworn I told you not to make it a derivation when you suggested to do that (around the time of asking you to make CONFIG_RTC tell users not to enable it on PPC, since they probably want CONFIG_PPC_RTC). It's still not right in 2.3.0 since it's a derivation, when it's an either/or question (drivers/char/rtc.c does work on some machines, and not others). But you also seem to be ignoring my point about CML2 adding in new features/enhancements at once instead of being a replacement and then patches to add new features which (have been|need to be) discussed more. -- 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] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 09:33:01AM -0700, Steven Cole wrote: On Friday 15 February 2002 09:04, Tom Rini wrote: On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [much sippage] The big problem in CML2 is python (and python2). This is a red herring. People bitch and moan about it, but it's not a problem. Agreed, but it is a minor irritation for me, and could be a major irritation for others. On my RH 7.2 system, the lpd startup scripts don't work with anything but Python 1.5.2, so I have to switch things around a little if I want to get lpd working. This is very easy to do, and I don't have this problem on Mandrake which is fully compatible with Python 2. It's possible to have python 2.x be 'python2'. The real problem with CML2 is 'enhancements' that come with the package. The first round of CML2 that goes into the kernel needs to match the current set, bug/feature for bug/feature, and counter intuitive to normal user question for coutner intuituve to normal user question. This is an extremely important point. When applications such as make xconfig and make menuconfig have been around a long time, a set of users will exist who will STRONGLY resist any change to the look and feel and operation of the interfaces to those programs. It's not so much the look feel (which seems to have been copied well by now), but policy changes. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] 2048 max variables in xconfig?
Hey all. I've just run into a situation where xconfig won't run because there's 2048 variables for it to deal with. If I'm reading the source right, I should just be able to bump VARTABLE_SIZE in scripts/tkparse.c and everything should just work (and from my quick testing, it does). But I figured I'd check with more knowledgeable people, so is this right? Thanks. -- 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
On Sun, Dec 30, 2001 at 05:14:22PM +, David Woodhouse wrote: [EMAIL PROTECTED] said: unless (ISA or PCI) suppress dependent IDE Just a minor point, but what about non-PCI/ISA ide? Eric is merely representing the _existing_ rules. Changing the behaviour can come later - that shouldn't be done at the same time as introducing CML2. Yes, but what I was getting at was that these constraints will change (either because they were incorrect or no longer aplicable). Either way, why not fix bugs now? (since there are non-PCI/ISA ide, which is why I kept that example to start with). -- 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
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. 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
Re: [kbuild-devel] Re: State of the new config build system
On Fri, Dec 28, 2001 at 02:22:01AM +0100, Dave Jones wrote: On Thu, 27 Dec 2001, Eric S. Raymond wrote: That is such an unutterably horrible concept that the very tentacles of Cthulhu himself must twitch in dread at the thought. The last thing anyone sane wants to do is have to maintain two parallel build systems at the same time. Funny, I could have sworn I read this was Keith's intention at least for a few pre's. Maybe I misinterpreted his intentions. I think Keith wanted a very small time window tho (~24 hrs, barring big supprises). But if we're going to be worried about the build time, kbuild-2.5 and cml2 aren't co-dependant, yes? I know kbuild-2.5 works w/o cml2, and last I tried (ages ago admitedly) cml2 didn't need kbuild-2.5. So we could, in theory dump cml1 quickly but leave the old Makefiles for a bit longer. Or if Keith thinks he can start on the speed problems soon, just plod along for a few releases. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] PPC, take 2
Okay, here's a patch for 2.4.16 to get PPC mostly working. It still only compiles up to 'vmlinux' (I'm waiting for a 2.4.17 or 2.4.18-pre based update to start on the boot stuffs), but should have all of the nits pointed out before fixed. It also makes -Wa,-mppc64bridge a constant extra_aflag (I _think_ I did this part right, but the code doesn't normally compile in the tree I was trying, so I only saw that yes indeed head.S got the right flags). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/8260_io/Makefile.inWed Dec 19 16:12:48 2001 @@ -0,0 +1,3 @@ +select(CONFIG_8260 commproc.o uart.o) +select(CONFIG_8260 CONFIG_FEC_ENET fcc_enet.o) +select(CONFIG_8260 CONFIG_SCC_ENET enet.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/8xx_io/Makefile.in Wed Dec 19 16:13:03 2001 @@ -0,0 +1,4 @@ +select(CONFIG_8xx commproc.o uart.o) +select(CONFIG_8xx CONFIG_FEC_ENET fec.o) +select(CONFIG_8xx CONFIG_SCC_ENET enet.o) +select(CONFIG_UCODE_PATCH micropatch.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/amiga/Makefile.in Thu Dec 27 09:28:18 2001 @@ -0,0 +1,5 @@ +expsyms(amiga_ksyms.o) + +select(CONFIG_APUS config.o amiints.o cia.o time.o bootinfo.o amisound.o + chipram.o amiga_ksyms.o) +select(CONFIG_AMIGA_PCMCIA pcmcia.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/boot/config.install-2.5Wed Dec 19 16:10:16 2001 @@ -0,0 +1,34 @@ +mainmenu_name PPC Installation + +define_bool CONFIG_VMLINUX y + +bool 'Use a prefix on install paths' CONFIG_INSTALL_PREFIX +if [ $CONFIG_INSTALL_PREFIX = y ]; then + string ' Prefix for install paths' CONFIG_INSTALL_PREFIX_NAME +fi +string 'Where to install the kernel' CONFIG_INSTALL_KERNEL_NAME +/lib/modules/KERNELRELEASE/KERNELBASENAME +bool 'Install System.map' CONFIG_INSTALL_SYSTEM_MAP +if [ $CONFIG_INSTALL_SYSTEM_MAP = y ]; then + string ' Where to install System.map' CONFIG_INSTALL_SYSTEM_MAP_NAME +/lib/modules/KERNELRELEASE/System.map +fi +bool 'Install .config' CONFIG_INSTALL_CONFIG +if [ $CONFIG_INSTALL_CONFIG = y ]; then + string ' Where to install .config' CONFIG_INSTALL_CONFIG_NAME +/lib/modules/KERNELRELEASE/.config +fi +if [ $CONFIG_VMLINUX != y ]; then + bool ' Install vmlinux for debugging' CONFIG_INSTALL_VMLINUX + if [ $CONFIG_INSTALL_VMLINUX = y ]; then +string 'Where to install vmlinux' CONFIG_INSTALL_VMLINUX_NAME +/lib/modules/KERNELRELEASE/vmlinux + fi +fi +bool 'Run a post-install script or command' CONFIG_INSTALL_SCRIPT +if [ $CONFIG_INSTALL_SCRIPT = y ]; then + string ' Post-install script or command name' CONFIG_INSTALL_SCRIPT_NAME +fi + +# FIXME: These critical config options should be in arch/$(ARCH)/config.in. For +# coexistence of kbuild 2.4 and 2.5 it is easier to put them here, move them +# later. KAO + +define_string CONFIG_KBUILD_CRITICAL_ARCH_PPC CONFIG_6xx CONFIG_8xx \ + CONFIG_4xx CONFIG_ALTIVEC --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/kernel/Makefile.in Thu Dec 27 09:25:02 2001 @@ -0,0 +1,48 @@ +extra_cflags(pmac_setup.o $(src_includelist /drivers/scsi)) +extra_cflags(prep_setup.o $(src_includelist /drivers/sound)) + +select($(notdir $(arch_head))) + +expsyms(ppc_ksyms.o prep_setup.o time.o) + +select(entry.o traps.o irq.o idle.o time.o misc.o process.o signal.o ptrace.o + align.o semaphore.o syscalls.o setup.o cputable.o ppc_htab.o) + +select(CONFIG_KGDB ppc-stub.o) +select(CONFIG_MODULES ppc_ksyms.o) +select(CONFIG_PCI pci.o pci-dma.o) +select(CONFIG_SMP smp.o) +select(CONFIG_TAU temp.o) + +select(CONFIG_4xx ppc4xx_pic.o) +select(CONFIG_OAK oak_setup.o) +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 CONFIG_SMP pmac_smp.o chrp_smp.o) +select(CONFIG_BOOTX_TEXT btext.o) +select(CONFIG_NVRAM pmac_nvram.o) +select(CONFIG_PMAC_BACKLIGHT pmac_backlight.o) +select(CONFIG_PMAC_PBOOK sleep.o) +select(CONFIG_PPC_RTAS error_log.o proc_rtas.o) +select(CONFIG_PREP_RESIDUAL residual.o) +select(CONFIG_APUS apus_setup.o) +select(CONFIG_APUS CONFIG_PCI apus_pci.o) +select(CONFIG_GEMINI gemini_prom.o gemini_pci.o gemini_setup.o open_pic.o) + +select(CONFIG_8xx m8xx_setup.o ppc8xx_pic.o) +select(CONFIG_8xx CONFIG_PCI qspan_pci.o) +select(CONFIG_8xx !CONFIG_MATH_EMULATION softemu8xx.o) +select(CONFIG_MBX i8259.o) +select(CONFIG_8260 m8260_setup.o ppc8260_pic.o) +select(CONFIG_POWER4 xics.o) + +uses_asm_offsets(entry.o) +uses_asm_offsets(misc.o) +uses_asm_offsets(l2cr.o) +uses_asm_offsets($(notdir $(arch_head))) +uses_asm_offsets(gemini_prom.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/lib/Makefile.inMon Dec 17 15:02:56 2001 @@ -0,0 +1,4 @@ +expsyms(dec_and_lock.o) + +select
[kbuild-devel] PPC, take 1
Okay. With the various patches Keith has posted (and using kbuild-2.4 for vmlinux - zImage), I've gotten two different boards compiled and booted. These still have the various debugging statements in, but aside from that does anyone see any problems/nits I should go and fix? (I also left out the files I had to modify for relative includes for now). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/8260_io/Makefile.inWed Dec 19 16:12:48 2001 @@ -0,0 +1,3 @@ +select(CONFIG_8260 commproc.o uart.o) +select(CONFIG_8260 CONFIG_FEC_ENET fcc_enet.o) +select(CONFIG_8260 CONFIG_SCC_ENET enet.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/8xx_io/Makefile.in Wed Dec 19 16:13:03 2001 @@ -0,0 +1,4 @@ +select(CONFIG_8xx commproc.o uart.o) +select(CONFIG_8xx CONFIG_FEC_ENET fec.o) +select(CONFIG_8xx CONFIG_SCC_ENET enet.o) +select(CONFIG_UCODE_PATCH micropatch.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/amiga/Makefile.in Mon Dec 17 15:14:19 2001 @@ -0,0 +1,5 @@ +expsyms(amiga_ksyms.o) + +select(CONFIG_APUS config.o amiints.o cia.o time.o bootinfo.o amisound.o \ + chipram.o amiga_ksyms.o) +select(CONFIG_AMIGA_PCMCIA pcmcia.o) --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/boot/config.install-2.5Wed Dec 19 16:10:16 2001 @@ -0,0 +1,34 @@ +mainmenu_name PPC Installation + +define_bool CONFIG_VMLINUX y + +bool 'Use a prefix on install paths' CONFIG_INSTALL_PREFIX +if [ $CONFIG_INSTALL_PREFIX = y ]; then + string ' Prefix for install paths' CONFIG_INSTALL_PREFIX_NAME +fi +string 'Where to install the kernel' CONFIG_INSTALL_KERNEL_NAME +/lib/modules/KERNELRELEASE/KERNELBASENAME +bool 'Install System.map' CONFIG_INSTALL_SYSTEM_MAP +if [ $CONFIG_INSTALL_SYSTEM_MAP = y ]; then + string ' Where to install System.map' CONFIG_INSTALL_SYSTEM_MAP_NAME +/lib/modules/KERNELRELEASE/System.map +fi +bool 'Install .config' CONFIG_INSTALL_CONFIG +if [ $CONFIG_INSTALL_CONFIG = y ]; then + string ' Where to install .config' CONFIG_INSTALL_CONFIG_NAME +/lib/modules/KERNELRELEASE/.config +fi +if [ $CONFIG_VMLINUX != y ]; then + bool ' Install vmlinux for debugging' CONFIG_INSTALL_VMLINUX + if [ $CONFIG_INSTALL_VMLINUX = y ]; then +string 'Where to install vmlinux' CONFIG_INSTALL_VMLINUX_NAME +/lib/modules/KERNELRELEASE/vmlinux + fi +fi +bool 'Run a post-install script or command' CONFIG_INSTALL_SCRIPT +if [ $CONFIG_INSTALL_SCRIPT = y ]; then + string ' Post-install script or command name' CONFIG_INSTALL_SCRIPT_NAME +fi + +# FIXME: These critical config options should be in arch/$(ARCH)/config.in. For +# coexistence of kbuild 2.4 and 2.5 it is easier to put them here, move them +# later. KAO + +define_string CONFIG_KBUILD_CRITICAL_ARCH_PPC CONFIG_6xx CONFIG_8xx \ + CONFIG_4xx CONFIG_ALTIVEC --- /dev/null Wed Dec 31 17:00:00 1969 +++ arch/ppc/kernel/Makefile.in Wed Dec 19 21:30:47 2001 @@ -0,0 +1,70 @@ +ifsel(CONFIG_PPC64BRIDGE) +extra_aflags_all(-Wa-mppc64bridge) +endif + +extra_cflags(pmac_setup.o $(src_includelist /drivers/scsi)) +extra_cflags(prep_setup.o $(src_includelist /drivers/sound)) +# Start off with 'head.o' change as needed. +#HEAD-y= head.o +#HEAD-$(CONFIG_4xx):= head_4xx.o +#HEAD-$(CONFIG_8xx):= head_8xx.o + +#select($(HEAD-y)) +dummy := $(shell echo arch_head=$(arch_head) 2) +dummy := $(shell echo notdir arch_head=$(notdir $(arch_head)) 2) +select($(notdir $(arch_head))) + +expsyms(ppc_ksyms.o prep_setup.o time.o) +select(entry.o traps.o irq.o idle.o time.o misc.o process.o signal.o ptrace.o align.o +semaphore.o syscalls.o setup.o cputable.o ppc_htab.o) + +select(CONFIG_6xx l2cr.o) +select(CONFIG_MODULES ppc_ksyms.o) +select(CONFIG_POWER4 xics.o) +select(CONFIG_PCI pci.o pci-dma.o) +select(CONFIG_KGDB ppc-stub.o) +select(CONFIG_SMP smp.o) +select(CONFIG_4xx ppc4xx_pic.o) +select(CONFIG_OAK oak_setup.o) +select(CONFIG_WALNUT walnut_setup.o) +select(CONFIG_TAU temp.o) +ifsel(CONFIG_WALNUT) +select(CONFIG_PCI galaxy_pci.o) +endif +select(CONFIG_8xx m8xx_setup.o ppc8xx_pic.o) +ifsel(CONFIG_8xx) +select(CONFIG_PCI qspan_pci.o) +ifnsel(CONFIG_MATH_EMULATION) +select(softemu8xx.o) +endif +endif +select(CONFIG_MBX i8259.o) +select(CONFIG_APUS apus_setup.o) +ifsel(CONFIG_APUS) +select(CONFIG_PCI apus_pci.o) +endif +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_NVRAM pmac_nvram.o) +select(CONFIG_PMAC_BACKLIGHT pmac_backlight.o) +select(CONFIG_PMAC_PBOOK sleep.o) +select(CONFIG_PREP_RESIDUAL residual.o) +select(CONFIG_PPC_RTAS error_log.o proc_rtas.o) +select(CONFIG_GEMINI gemini_prom.o gemini_pci.o gemini_setup.o open_pic.o) +select(CONFIG_8260 m8260_setup.o ppc8260_pic.o) +select(CONFIG_BOOTX_TEXT btext.o) + +ifsel(CONFIG_SMP) +select(CONFIG_ALL_PPC pmac_smp.o chrp_smp.o) +endif
Re: [kbuild-devel] PPC, take 1
On Fri, Dec 21, 2001 at 07:34:35AM +1100, Keith Owens wrote: On Thu, 20 Dec 2001 08:09:19 -0700, Tom Rini [EMAIL PROTECTED] wrote: Okay. With the various patches Keith has posted (and using kbuild-2.4 for vmlinux - zImage), I've gotten two different boards compiled and booted. These still have the various debugging statements in, but aside from that does anyone see any problems/nits I should go and fix? (I also left out the files I had to modify for relative includes for now). Do you have to change the source code to handle relative includes? Unless you changed the kbuild 2.4 Makefiles as well, changing source will prevent the use of kbuild 2.4 after your patch is applied. I avoided changing source for kbuild 2.5 unless the change was also 2.4 compatible. You should be able to handle relative includes with extra cflags (and a lot of FIXME comments). Yeah, I did the 'proper' kbuild-2.5 only fix for now. What would the proper extra flag be for #include ../../../drivers/scsi/sd.h tho? $(src_listinc /) or so? --- /dev/nullWed Dec 31 17:00:00 1969 +++ arch/ppc/amiga/Makefile.in Mon Dec 17 15:14:19 2001 @@ -0,0 +1,5 @@ +expsyms(amiga_ksyms.o) + +select(CONFIG_APUS config.o amiints.o cia.o time.o bootinfo.o amisound.o \ +chipram.o amiga_ksyms.o) No need to use trailing '\', unless they are raw make commands like CFLAGS +=. Pre-processor commands do not need continuation markers and they just look ugly. Ah, okay. --- /dev/nullWed Dec 31 17:00:00 1969 +++ arch/ppc/kernel/Makefile.in Wed Dec 19 21:30:47 2001 @@ -0,0 +1,70 @@ +ifsel(CONFIG_PPC64BRIDGE) +extra_aflags_all(-Wa-mppc64bridge) +endif Should the extra aflags for ppc64bridge be set in Makefile.defs.config so they affect everything? Also those flags look wrong, I would expect -Wa,-mppc64bridge, not -Wa-mppc64bridge. Yeah, that's a typo. Thanks. I'll ask the ppc64 people if all .S files should get it or what. +ifsel(CONFIG_WALNUT) +select(CONFIG_PCI galaxy_pci.o) +endif select(CONFIG_PCI CONFIG_WALNUT galaxy_pci.o) Yeah, that came out of pass-one (directish translation). I found the select(CONFIG_A ... CONFIG_N foo.o) later on. I'll go fix those bits and post a patch (are you planning on a 2.4.16-3 or going to wait until 2.4.17 is out?). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] KBUILD_QUITE?
Ages ago, you can make kbuild-2.5 be a lot more verbose about what it was doing. I think it involved setting (or unsetting KBUILD_QUITE), but I don't see anything like that in Documentation/kbuild/kbuild-2.5.txt now. Is there something like this still? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Using other arch includes + objdir != srcdir
On PPC, the APUS platform (which is an m68k + PPC upgrade), we need to include a bunch of m68k headers. How should this be done w/ kbuild-2.5? Right now the files do #include asm-m68k/foo.h, but this fails when srcdir != objdir: CC arch/ppc/kernel/irq.o In file included from /home/trini/work/kernel/kbuild/linux-2.4.16/arch/ppc/kernel/irq.c:62: .tmp_include/src_000/asm/amigahw.h:9: asm-m68k/amigahw.h: No such file or directory pp_makefile3: Main command (pid 22079) returned 1 make[1]: *** [arch/ppc/kernel/irq.o] Error 1 Are we going to end up having go make amigahw.h On PPC, the APUS platform (which is an m68k + PPC upgrade), we need to include a bunch of m68k headers. How should this be done w/ kbuild-2.5? Right now the files do #include asm-m68k/foo.h and then some specific #defines, but this fails when srcdir != objdir: CC arch/ppc/kernel/irq.o In file included from /home/trini/work/kernel/kbuild/linux-2.4.16/arch/ppc/kernel/irq.c:62: .tmp_include/src_000/asm/amigahw.h:9: asm-m68k/amigahw.h: No such file or directory pp_makefile3: Main command (pid 22079) returned 1 make[1]: *** [arch/ppc/kernel/irq.o] Error 1 What's the correct way to fix this? -- 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] Using other arch includes + objdir != srcdir
On Wed, Dec 19, 2001 at 01:27:19PM -0700, Tom Rini wrote: On PPC, the APUS platform (which is an m68k + PPC upgrade), we need to include a bunch of m68k headers. How should this be done w/ kbuild-2.5? Right now the files do #include asm-m68k/foo.h, but this fails when srcdir != objdir: CC arch/ppc/kernel/irq.o In file included from /home/trini/work/kernel/kbuild/linux-2.4.16/arch/ppc/kernel/irq.c:62: .tmp_include/src_000/asm/amigahw.h:9: asm-m68k/amigahw.h: No such file or directory pp_makefile3: Main command (pid 22079) returned 1 make[1]: *** [arch/ppc/kernel/irq.o] Error 1 Or rather, is there any better way than doing extra_cflags_all($(src_includelist /include)) (or doing it per-file..) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: .tmp_targets failing?
On Thu, Dec 20, 2001 at 02:02:58AM +1100, Keith Owens wrote:
On Tue, 18 Dec 2001 08:16:08 -0700,
Tom Rini [EMAIL PROTECTED] wrote:
On Tue, Dec 18, 2001 at 02:38:05PM +1100, Keith Owens wrote:
arch_head must be defined in arch/$(ARCH)/Makefile.defs.noconfig. The
value of arch_head is used by pp_makefile2 to generate the global
makefile, Makefile.defs.config is not read until after the global
makefile is created, in fact Makefile.defs.config is only read by the
global makefile.
There is a bug in pp_makefile2.c, trim_arch_head() assumes that
arch_head is always set to at least one string. If you really need an
empty arch_head, change trim_arch_head() from
for (a = arch_head; *a; ++a) {
to
for (a = arch_head; a *a; ++a) {
Okay. Unless we do some sort of 'magic' later on to make
arch/ppc/kernel/head.S one of
arch/ppc/kernel/head_{iSeries,6xx,8xx,4xx}.S.
With the above change, it seems to be OK now.
The patch below against kbuild-2.5-2.4.16-2 changes where
arch/$(ARCH)/Makefile.defs.config is read. It used to be read in the
global makefile, long after .config had been generated, it is now read
from scripts/Makefile-2.5. Unfortunately this introduces a nasty
recursion problem, have a barf bag handy while you read the solution.
I got one warning w/ this:
awk: cmd. line:1: (FILENAME=- FNR=6) warning: use `PROCINFO[pid]'
instead of `/dev/pid'
I've got things compiling linking now. Now I just need to see why it
doesn't boot :)
--
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] KBUILD_QUITE?
On Thu, Dec 20, 2001 at 09:15:32AM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 13:06:46 -0700, Tom Rini [EMAIL PROTECTED] wrote: Ages ago, you can make kbuild-2.5 be a lot more verbose about what it was doing. I think it involved setting (or unsetting KBUILD_QUITE), but I don't see anything like that in Documentation/kbuild/kbuild-2.5.txt now. Is there something like this still? Documentation/kbuild/kbuild-2.5.txt line 1787, under Controlling kbuild. I'm blind and I make typos, whoops. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Using other arch includes + objdir != srcdir
On Thu, Dec 20, 2001 at 09:45:16AM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 13:27:19 -0700, Tom Rini [EMAIL PROTECTED] wrote: On PPC, the APUS platform (which is an m68k + PPC upgrade), we need to include a bunch of m68k headers. How should this be done w/ kbuild-2.5? Try this (untested). It should create a symlink for asm-m68k under $KBUILD_OBJTREE/.tmp_include/src_000/. Okay, that seems to do the trick too. -- 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: .tmp_targets failing?
On Thu, Dec 20, 2001 at 01:24:48PM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 18:59:13 -0700, Tom Rini [EMAIL PROTECTED] wrote: # 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 arch_head := arch/ppc/kernel/head_4xx.o endif ifneq ($(subst n,,$(CONFIG_8xx)),) CFLAGS += -Wa,-m860 arch_head := arch/ppc/kernel/head_8xx.o endif ifneq ($(subst n,,$(CONFIG_PPC64BRIDGE)),) CFLAGS += -Wa,-mppc64bridge endif Time for some debug statements. and confusion perhaps? $ make -f Makefile-2.5 CONFIG_4xx= CONFIG_8xx= Using ARCH='ppc' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar' [snip] $ env | grep KBUILD KBUILD_OBJTREE=/home/trini/work/kernel/kbuild/linux-2.4.16/ppc $ grep 8xx ppc/.config CONFIG_8xx=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: .tmp_targets failing?
On Thu, Dec 20, 2001 at 02:22:03PM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 19:29:32 -0700, Tom Rini [EMAIL PROTECTED] wrote: $ make -f Makefile-2.5 CONFIG_4xx= CONFIG_8xx= Using ARCH='ppc' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar' [snip] $ env | grep KBUILD KBUILD_OBJTREE=/home/trini/work/kernel/kbuild/linux-2.4.16/ppc $ grep 8xx ppc/.config CONFIG_8xx=y Looks like it is not including .config for some reason. In scripts/Makefile-2.5 find the comment # Evaluate any settings that depend on .config. and replace the next section of code with this. Okay. If I do make -f Makefile-2.5 installable I get: MAKECMDGOALS=installable filter= passed filter before CONFIG_8xx= included .config after CONFIG_8xx=y CONFIG_4xx= CONFIG_8xx=y arch_head for CONFIG_8xx=arch/ppc/kernel/head_8xx.o Using ARCH='ppc' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar' Generating global Makefile phase 1 (find all inputs) phase 2 (evaluate selections) phase 5 (dependencies from previous build) phase 3 (write global makefile) Starting phase 4 (build) for installable make[1]: *** No rule to make target `arch/ppc/kernel/head_8xx.o', needed by `init/compile.h'. Stop. But if I just do 'make -f Makefile-2.5' I get the same error as before. -- 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: .tmp_targets failing?
On Thu, Dec 20, 2001 at 03:06:19PM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 20:41:18 -0700, Tom Rini [EMAIL PROTECTED] wrote: Okay. If I do make -f Makefile-2.5 installable I get: MAKECMDGOALS=installable filter= passed filter before CONFIG_8xx= included .config after CONFIG_8xx=y CONFIG_4xx= CONFIG_8xx=y arch_head for CONFIG_8xx=arch/ppc/kernel/head_8xx.o Using ARCH='ppc' AS='as' LD='ld' CC='/usr/bin/gcc' CPP='/usr/bin/gcc -E' AR='ar' HOSTAS='as' HOSTLD='gcc' HOSTCC='gcc' HOSTAR='ar' Generating global Makefile phase 1 (find all inputs) phase 2 (evaluate selections) phase 5 (dependencies from previous build) phase 3 (write global makefile) Starting phase 4 (build) for installable make[1]: *** No rule to make target `arch/ppc/kernel/head_8xx.o', needed by `init/compile.h'. Stop. But if I just do 'make -f Makefile-2.5' I get the same error as before. Make thinks that the result of filtering a null string is not equal to itself NUL != NUL :(. Replace [snip] Okay, if I do that and add in: HEAD-y = head.o HEAD-$(CONFIG_8xx) := head_8xx.o HEAD-$(CONFIG_4xx) := head_4xx.o select($(HEAD-y)) Things get farther. Dunno if it'll select the right head for linking tho, but .tmp_env has arch_head set right (so why can't arch/ppc/kernel/Makefile.in use it?) -- 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: .tmp_targets failing?
On Thu, Dec 20, 2001 at 03:24:28PM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 21:14:47 -0700, Tom Rini [EMAIL PROTECTED] wrote: Okay, if I do that and add in: HEAD-y = head.o HEAD-$(CONFIG_8xx) := head_8xx.o HEAD-$(CONFIG_4xx) := head_4xx.o select($(HEAD-y)) Things get farther. Dunno if it'll select the right head for linking tho, but .tmp_env has arch_head set right (so why can't arch/ppc/kernel/Makefile.in use it?) Do this in arch/ppc/kernel/Makefile.in dummy := $(shell echo arch_head=$(arch_head) 2) dummy := $(shell echo notdir arch_head=$(notdir $(arch_head)) 2) select($(notdir $(arch_head))) Starting phase 4 (build) for installable arch_head=arch/ppc/kernel/head_8xx.o notdir arch_head=arch/ppc/kernel/head_8xx.o make[1]: *** No rule to make target `arch/ppc/kernel/head_8xx.o', needed by `init/compile.h'. Stop. Check $KBUILD_OBJTREE/.tmp_database under reldir /arch/ppc/kernel/, select should contain (y_ /arch/ppc/kernel/head_xxx.o). select (y_ /arch/ppc/kernel/arch/ppc/kernel/head_8xx.o) -- 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: .tmp_targets failing?
On Thu, Dec 20, 2001 at 04:24:32PM +1100, Keith Owens wrote: On Wed, 19 Dec 2001 21:32:31 -0700, Tom Rini [EMAIL PROTECTED] wrote: Starting phase 4 (build) for installable arch_head=arch/ppc/kernel/head_8xx.o notdir arch_head=arch/ppc/kernel/head_8xx.o make[1]: *** No rule to make target `arch/ppc/kernel/head_8xx.o', needed by `init/compile.h'. Stop. Check $KBUILD_OBJTREE/.tmp_database under reldir /arch/ppc/kernel/, select should contain (y_ /arch/ppc/kernel/head_xxx.o). select (y_ /arch/ppc/kernel/arch/ppc/kernel/head_8xx.o) kbuild 2.5 $(notdir) did not correctly handle unexpanded variables. Okay, all of these seem to lead to a mostly-working kernel. I'll post all of the Makefiles whatnot tomorrow once I test-compile a few more things. -- 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: Re: Using other arch includes + objdir != srcdir
On Thu, Dec 20, 2001 at 12:25:03PM +1100, Keith Owens wrote: On Thu, 20 Dec 2001 09:45:16 +1100, Keith Owens [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2001 13:27:19 -0700, Tom Rini [EMAIL PROTECTED] wrote: On PPC, the APUS platform (which is an m68k + PPC upgrade), we need to include a bunch of m68k headers. How should this be done w/ kbuild-2.5? Try this (untested). It should create a symlink for asm-m68k under $KBUILD_OBJTREE/.tmp_include/src_000/. Index: 16.35/Makefile-2.5 --- 16.35/Makefile-2.5 Sun, 16 Dec 2001 01:01:02 +1100 kaos (linux-2.4/E/d/40_Makefile-2 1.32.2.14 644) +++ 16.35(w)/Makefile-2.5 Thu, 20 Dec 2001 09:40:31 +1100 kaos (linux-2.4/E/d/40_Makefile-2 1.32.2.14 644) @@ -94,6 +94,12 @@ export KBUILD_WRITABLE check_writable # A list of directories under linux/include to scan, excluding asm-$(ARCH). KBUILD_INCLUDE_DIRS:= linux math-emu net pcmcia scsi video asm-generic +# The APUS platform (m68k + PPC upgrade) needs to include a bunch of m68k +# headers via #include asm-m68k/xxx.h. Why, oh why do they do these things? +# Since .config is not available yet, add asm-m68k for all PPC platforms. +ifeq ($(ARCH),ppc) + KBUILD_INCLUDE_DIRS += asm-m68k +endif # Unfortunately the make 'export' command only applies to commands in rules. # Exported variables are not available to $(shell) commands, at least up to Tom, please back out the patch above and try this one. It restricts the extra include path to apus only instead of adding asm-m68k for all ppc compiles. May as well isolate the broken code as much as possible. I don't know if this is any better really, since it adds #ifdef CONFIG_APUS #include asm/amigafoo.h #endif. And since APUS doesn't currently compile (@#!@$) anyways, I can't see if the includes are now bogus. So I think for now we should be overly cautious and always do asm-m68k. -- 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] .tmp_targets failing?
On Tue, Dec 18, 2001 at 02:55:33PM +1100, Keith Owens wrote: On Tue, 18 Dec 2001 14:38:05 +1100, Keith Owens [EMAIL PROTECTED] wrote: arch_head must be defined in arch/$(ARCH)/Makefile.defs.noconfig. The value of arch_head is used by pp_makefile2 to generate the global makefile, Makefile.defs.config is not read until after the global makefile is created, in fact Makefile.defs.config is only read by the global makefile. Damn, you need .config to define arch_head, I am going to have to think about this. BTW, I think that the existing kbuild has race conditions in ppc, there are situations where you can change the .config but use the old HEAD value. Quite possibly. But in kbuild-2.5 terms, changing any of the processor variables would fall under the KBUILD_CRITICIAL stuffs. -- 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] 'distclean' on kbuild-2.5?
On Tue, Dec 18, 2001 at 02:53:37PM +1100, Keith Owens wrote: On Mon, 17 Dec 2001 20:28:43 -0700, Tom Rini [EMAIL PROTECTED] wrote: Where'd the 'distclean' target go in kbuild-2.5? Shouldn't it be at least a synonym for mrproper now? Why? With separate source and object trees there is no need for any clean, the source is always pure. With common source and object, make mrproper does the job. distclean is an obsolete target, I am reducing the number of kbuild targets. Well, if nothing else compatibility sake, and it's a stanardish target? -- 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] .tmp_targets failing?
On Tue, Dec 18, 2001 at 10:31:51AM +1100, Keith Owens wrote: On Mon, 17 Dec 2001 15:46:30 -0700, Tom Rini [EMAIL PROTECTED] wrote: Hey all. I'm trying to get PPC going again with kbuild-2.5, but I'm runnign into some wierd errors. Anyone know what would cause the .tmp_targets rule to fail with an error 139? If I change: 139 = 128+11 - sig 11 - SEGV. Probably pp_makefile2 is breaking. cd $KBUILD_OBJTREE source .tmp_env (sets the environment variables, except src/object) gdb scripts/pp_makefile2 r Where does it break? What is the backtrace? It was on a for loop over arch_head. If I put arch_head in arch/ppc/Makefile.defs.noconfig, I got to the point of finding (I think) problems w/ my Makefile.in's. Is it possible to set arch_head in arch/$(ARCH)/Makefile.defs.config? I get to the point of kbuild-2.5 telling me there's no rule to make target 'installable'. That makes no sense. Even without selecting a kernel format, the installable target is defined to be at least System.map. Check .tmp_global_makefile, find installable:, it should look like this. It didn't make sense to me either, so I'll assume that w/ the prior breakage things just went horrible. -- 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] call for eyes - kbuild 2.5 on alpha
On Sat, Dec 15, 2001 at 12:49:18PM +1100, Keith Owens wrote: On Fri, 14 Dec 2001 17:08:18 -0500, Ghozlane Toumi [EMAIL PROTECTED] wrote: - the most used kernel format in the alpha world is the vmlinux.gz rather than vmlinuz. is vmlinuz an standard for kbuild2.5, or should i keep the old vmlinuz.gz ? I want one standard name for vmlinux compressed with gzip - vmlinuz. Part of the problem with kbuild 2.4 is each arch did their own thing, I am trying to standardize. It helps documentation if nothing else. And does this mean everyone will now have a 'vmlinuxz' file instead of a vmlinux.gz too? I'm not sure how this will help documentation, except for maybe simpilify the 'help' for a target. BTW, I have been tweaking the top level Makefile.in and adding some new embedded targets from David Woodhouse, it now looks like this: # List all standard kernel formats and locations for all architectures. [snip] ifsel(CONFIG_VMLINUZ) KERNELFULLNAME:= vmlinuz endif This reminds me, are we going to have global rules for 'vmlinuz' too? ifsel(CONFIG_ZIMAGE) KERNELFULLNAME:= arch/$(ARCH)/boot/zImage endif What if your 'zImage' target has multiple outputs? Or what if you don't want to have your final image in arch/$(ARCH)/boot/ ? ifsel(CONFIG_VMLINUX_SREC) KERNELFULLNAME:= vmlinux.srec endif Ack, is someone going to include the zsrec (I assume srec == motorola S-record deal..) utility in the kernel too now? And will it be in a 'common' place for all of the arches that could use it? ifsel(CONFIG_VMLINUX_BIN) KERNELFULLNAME:= vmlinux.bin endif And what's the 'vmlinux.bin' file? objcopy -O binary or ? -- 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] call for eyes - kbuild 2.5 on alpha
On Sat, Dec 15, 2001 at 12:49:18PM +1100, Keith Owens wrote: I want one standard name for vmlinux compressed with gzip - vmlinuz. Part of the problem with kbuild 2.4 is each arch did their own thing, I am trying to standardize. It helps documentation if nothing else. After thinking about this abit more, I think it sounds like kbuild-2.5 is trying to make all of the arches do the same thing, and that will be a bit of a problem. Right now each of the arches has a few commonalities. There's a 'zImage' target, and almost everyone makes some sort of gzip'ed vmlinux. But that's about it. On PPC the 'zImage' target will produce at most 5 distinct zImages at once. We also have 4 different ways of writing out the program that actually sets up and runs Linux, and about a dozen different formats for the kernel. So aside from having one place that asks 'What do you want to build for your kernel' (which on PPC could actually be a set of bool's so we could build a zImage.srec and zImage.elf and zImage.bin (ELF header removed)) and not having to have arch-dependant help texts (maybe), I'm not sure what's gained. -- 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] call for eyes - kbuild 2.5 on alpha
On Fri, Dec 14, 2001 at 05:08:18PM -0500, Ghozlane Toumi wrote: - the most used kernel format in the alpha world is the vmlinux.gz rather than vmlinuz. is vmlinuz an standard for kbuild2.5, or should i keep the old vmlinuz.gz ? Why can't the 'VMLINUZ' target produce a vmlinux.gz on alpha? - Is there a way *not to* change the main Makefile.in when adding targets other than vmlinux/z ( and shouldn't we remove any reference to bzimage/zimage from the main Makefile.in as it is an ix86 only kernel format) ? Supposedly we'll be able to suppress options that aren't needed on an arch.. -- 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] kbuild-2.5 and the apha
On Tue, Dec 11, 2001 at 06:48:14PM -0500, Ghozlane Toumi wrote: now the thing is that i'd like to add those new tagets to the configuration tools and config help . With the config.install-2.5 everything should be ok, but i'm not sure the non-alpha guys will be happy to see in the help 3-4 build targets with no meaning for them ... There's already lots of help entries for non-global options. Is there a way we could split the help entries into arch specific entries ? like using config variables CONFIG_INSTALL_$ARCH_VMLINUX or something ? This sounds sort-of like a good idea. On powermac and chrp, building a 'vmlinux' is currently a good idea for the final target, for example. That way each arch would only see it's build targets .. is it doable ? I take it by this you modified the help msg for the default target that alpha ends up with? -- 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] kbuild-2.5 and the apha
On Tue, Dec 11, 2001 at 09:38:58PM -0500, Ghozlane Toumi wrote: I was talking about the new CONFIG_INSTALL_* configuration options introduced by kbuild-2.5, and more specificaly of the options used to choose the build targets . as CML1 uses the first entry to get the help, we have to put in the help all the targets on all the arches, ouch ... hopefully this help limitation will go away with CML2. Yes, but there will still be lots of options that aren't global :) The BZIMAGE help text for example will be x86 only. We might want to allow for (or default to) going from CONFIG_INSTALL_ARCH_TARGET to CONFIG_INSTALL_TARGET, since not all targets mean the same thing all of the time. Or we make sure the descriptions are generic enough to fit (s/lilo/bootloader/, et al). -- 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] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 02:29:58PM +0100, Christoph Hellwig wrote: On Tue, Dec 04, 2001 at 08:16:40AM -0500, Eric S. Raymond wrote: N separate implementations means N dialects and N**2 compatibility problems. Nicer just to have *one* parser, *one* compiler, and *one* service class that supports several thin front-end layers, yes? No? Oh man. When you think one implementation of a 'standard' is better then multiple go to the MS world. Wouldn't multiple tools which don't quite work to a 'standard' better represent the MS world? Which is what all of the cml1 tools do. All of these tools just require the runtime contained in the LSB and no funky additional script languages. Also none needs a binary intermediate representation of the config. I quote Linus at the 2.5 kernel summit: Python is not an issue. Unless and until he changes his mind about that, waving around this kind of argument is likely to do your case more harm than good. For me (and others) it is an issues. Why? If you want to re-open the case for saving CML1, you'd be better off demonstrating how CML1 can be used to (a) automatically do implied side-effects when a symbol is changed, With mconfig it can be implemented easily - I don't see the point in doing it, though. To show that CML1 doesn't need to die yet. (b) guarantee that the user cannot generate a configuration that violates stated invariants, and What do you mean with that? That you can't turn on CONFIG_FOO_BAR unless CONFIG_FOO is on. This is getting at things like USB V4L devices which need CONFIG_USB and CONFIG_VIDEODEV set to !n. This is done poorly in CML1. (c) unify the configuration tree so that the equivalents of arch/* files never suffer from lag or skew when an architecture-independent feature is added to the kernel. One toplevel config file can be implemented in CML1 easily, using mconfig or the old and ugly tools, it's just a question of changeing the rule base in tree. Lots of changing of the Config.in files. -- 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] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:27:26PM +0100, Martin Dalecki wrote: Alan Cox wrote: Creating a dependency on Python? Is a non-issue. Current systems that are to run 2.5 or 2.6 are bloated beyond belief by glibc already, Python is nice and it does not create such unmaintainable mess. Whether Python2 - which means most users dont have it. Most users sure as hell shouldn't be playing with 2.5.x right now anyways. With any sort of 'luck' it'll be 6 months at least before 2.5.x becomes stable enough that it will probably compile all the time again and not have a random fs eating bug. In 6 months even woody might be frozen :) And then you will end with: python1.4x, python2, python3 rewrite in python1 and so on and so on. Say what? Python (with the exception of undocumented features) has been pretty good about compatiblity. If it works with 1.5.x and doesn't rely on undocumented features, it'll work with 2.0x, 2.1x and 2.2x. Thanks but NO thanks Then go help Greg Banks in his CML2-in-C project. -- 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] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:08:57PM +0100, Ra?l N??ez de Arenas Coronado wrote: Hi Matthias :) Creating a dependency on Python? Is a non-issue. Maybe for you. For me it *is* an issue. I don't like more and more dependencies for the kernel. I mean, if I can drop kbuild and keep on building the kernel with the old good 'make config' I won't worry, but otherwise I don't think that kernel building depends on something like Python. One of the things that I _think_ is happening is that lots of other scripts/ files are being redone, and thus removing them from the list, so in effect we're trading out one or two for just Python. Why must I install Python in order to compile the kernel? I don't understand this. I think there are better alternatives, but kbuild seems to be imposed any way. kbuild != CML2. It all boils down to the current 'language' having no real definitive spec, and having 3+ incompatible parsers. We could either try and tweak the language slightly (and probably make it even harder on external parsers) or throw it out and try again. ESR wrote CML2 with a Python interpreter, so it uses Python. The spec for CML2 is out there, and there's even a CML2-in-C project. If you don't want to use Python, go help (I believe Greg Banks is who ESR mentioned is in charge of it) that project out and then convince Linus to include it. You don't make the pen yourself when writing a letter either. I don't like to be forced in a particular pen, that's the reason why I use and develop for linux. To carry this analogy out a bit more, the details on how to make a pen exist, so if you don't like ESRs pen, go make your own. That's why a lot of people use Linux too. What are the precise issues with Python? Just claiming it is an issue is not useful for discussing this. Archive pointers are welcome. Well, let's start writing kernel drivers with Python, Perl, PHP, awk, etc... And, why not, C++, Ada, Modula, etc... The kernel should depend just on the compiler and assembler, IMHO. The right tools for the right job. C is good for the kernel. Python is good at manipulating strings. -- 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] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:26:27PM +, Alan Cox wrote: Python2 - which means most users dont have it. Most users sure as hell shouldn't be playing with 2.5.x right now anyways. With any sort of 'luck' it'll be 6 months at least before 2.5.x becomes stable enough that it will probably compile all the time again and not have a random fs eating bug. In 6 months even woody might be frozen :) It wont become stable if nobody can configure it because nobody will build it or run it. Lots of people build non stable kernels because its a) fun b) a way to learn and play with the system c) they might make their own small fix and mark not all of the them are demon kernel hackers. But they can't install python2? I _think_ there's src.rpms on Python.org that will install as python2 even... -- 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] Dead symbols
On Sun, Dec 02, 2001 at 09:47:41PM -0500, Eric S. Raymond wrote: The following symbols occur only in CML1 configuration files and not .c or .h files or makefiles. Can amy of these be eliminated entirely? This would help me cut the missing-help-entries list. [snip] PCI_PERMEDIA: arch/ppc/config.in This is because of a partial merge to Linus, ignore it. -- 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] Missing Configure,help entries need filling in
On Sat, Dec 01, 2001 at 12:26:08PM -0500, Eric S. Raymond wrote: We're down to 120 missing help entries. If you can fill some of these in, please send me a patch for Configure.help. [snip] I2C_ALGO8XX I2C_PPC405_ADAP I2C_PPC405_ALGO I2C_RPXLITE Please ignore these for now as the code isn't in the tree either. For the time being it would be more correct to comment out the config questions. UCODE_PATCH Once again: Motorola releases microcode updates for their 8xx CPM modules. The microcode update file has updates for IIC, SMC and USB. Currently only the USB update is available by default, if the MPC8xx USB option is enabled. If in doubt, say 'N' here. And yes, the USB driver isn't in the tree yet either. -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote: I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) I don't know What about other defaults? If 'vmlinuz' == 'zImage', this might be OK, otherwise we'd need something like: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE ZIMAGE.INITRD default ((X86 or IA64 or SPARC) ? VMLINUZ : (PPC) ? ZIMAGE : BZIMAGE) unless PPC suppress ZIMAGE.INITRD If I'm reading that right (and I don't know, wouldn't it be default ((IA64 or SPARC) ? VMLINUZ : BZIMAGE), ia64/sparc do vmlinuz, else bzImage). -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 12:53:42PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: On Thu, Nov 29, 2001 at 12:16:45PM -0500, Eric S. Raymond wrote: I think I may have a better idea. Let the default be a ? : name-valued expression. So your format choice could look something like this: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE default ((X86 or IA64 or SPARC) ? VMLINUZ : BZIMAGE) I don't know What about other defaults? If 'vmlinuz' == 'zImage', this might be OK, otherwise we'd need something like: choices kernel_format VMLINUX VMLINUZ IMAGE ZIMAGE BZIMAGE ZIMAGE.INITRD default ((X86 or IA64 or SPARC) ? VMLINUZ : (PPC) ? ZIMAGE : BZIMAGE) unless PPC suppress ZIMAGE.INITRD If I'm reading that right (and I don't know, wouldn't it be default ((IA64 or SPARC) ? VMLINUZ : BZIMAGE), ia64/sparc do vmlinuz, else bzImage). I'm not understanding your objection. Is it to the specific rule above, or the proposed mechanism? I'm just pointing out that we'll end up with somelike really long and ugly since there'll be at least 3 'defaults' and probably more. If you think it's better to have lots of the test ? a : b's nested instead of making these things architecutre-specific, that's fine I suppose. -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a Government is not reason, it is not eloquence, it is force; like fire, a troublesome servant and a fearful master. Never for a moment should it be left to irresponsible action. -- George Washington, in a speech of January 7, 1790 -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 01:15:03PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: I'm just pointing out that we'll end up with somelike really long and ugly since there'll be at least 3 'defaults' and probably more. If you think it's better to have lots of the test ? a : b's nested instead of making these things architecutre-specific, that's fine I suppose. It's a tradeoff. The alternative to a long, ugly declaration in one place would be a bunch of marginally shorter and less ugly declarations scattered to hellandgone through the ruleset. :-) Well, in arch/$(ARCH)/rules.cml or so. I know that the second alternative would be harder to compile and validate. I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT I judge that it would also be a net loss for humans maintaining the code -- too hard to be sure that you know what all the relevant declarations are. Better the big ugly declaration you know than the many smll declarations you know not... Er, but this is an arch-specific question. The humans maintaining it would be the maintainer for that arch, who really should know what's relevant. There's also less of a chance of someone goofying up and accidently forgetting to add unless MYARCH suppress FOOBOOTIMAGE that they just added. There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? -- a href=http://www.tuxedo.org/~esr/;Eric S. Raymond/a What is a magician but a practicing theorist? -- Obi-Wan Kenobi, 'Return of the Jedi' -- 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] CML2 choice funny
On Thu, Nov 29, 2001 at 01:30:27PM -0500, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: I don't know. How is it harder to validate choice kernel_format_PPC VMLINUX ZIMAGE ZNETBOOT default ZIMAGE choice kernel_format_ix86 VMLINUX ZIMAGE BZIMAGE BZDISK default BZIMAGE Than: choice kernel_format VMLINUX ZIMAGE BZIMAGE ZNETBOOT defeult ((X86) : BZIMAGE ? ((IA64 or SPARC) ? VMLINUZ : ZIMAGE)) unless X86 suppress BZIMAGE unless PPC suppress ZNETBOOT That's not a bad case. The case I'm worried about is the one where the choice menus get split into different files and can't be eyeballed at the same time easily. Me too. I'm sort of lost as to why this would all need to be in one file. If I understand things, there's one rules.cml for compile target and 'install' questions. Why? There will be per-arch questions which have no relevance to other arches. But even if those were each in a different rules.cml, I still don't see the problem. If there's a syntax error, the compiler will throw up and tell us where, right? What's a bad thing that could happen? There's a problem like this now with unless/suppress declarations, but I saw no way to avoid it there. I guess I didn't read the other posts thourghly enough, what's the exact problem? Information distributed through the ruleset in such a way that it's hard to know all the places a given symbol participates. On the compiler side of things or the human side of things? All of the rule files become one big file, sort of anyhow don't they? And if someone is asking about FOO in a horribly wierd (file) place, maybe they have a good reason to.. Or are totally missing something and will end up with some wierd behavior possibly. -- 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: '$*' Considered Harmful?
On Sun, Nov 18, 2001 at 08:48:22PM -0600, Peter Samuelson wrote: [I wrote] I don't see why we use $* at all -- of the 150 or so instances, it looks like they *all* could be replaced with $ or $@. The GNU make info page actually deprecates $* except for use with implicit rules. Oh and hey, look at that. Three of the usages are even buggy. # see arch/ppc/boot/common/Makefile It's unused here I think since nothing directly curses into a/p/b/common, it's always depened on by stuff in other directories. # see arch/ppc/boot/mbx/Makefile That's all gone. .. at least in the current PPC stuffs. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Export objs from an external Makefile?
Hey all. How do you do the 'export-objs' bits in a kernel module that's outside of the kernel? Thanks.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Export objs from an external Makefile?
On Fri, Oct 12, 2001 at 09:42:05AM +1000, Keith Owens wrote: On Thu, 11 Oct 2001 09:35:32 -0700, Tom Rini [EMAIL PROTECTED] wrote: Hey all. How do you do the 'export-objs' bits in a kernel module that's outside of the kernel? Thanks.. Compile with -DMODULE -DEXPORT_SYMTAB. If the kernel has modversions, add -DMODVERSIONS -include $(HPATH)/linux/modversions.h. The safest way is to compile a module in the kernel that exports the objects then copy the command, substituting the file names. I think I managed to get things right. I added -DEXPORT_SYMTAB to the default flags and added: CFLAGS_EXTRA+= $(shell if [ -f $(KERNEL_HEADERS)/linux/modversions.h ]; \ then echo -include \ $(KERNEL_HEADERS)/linux/modversions.h; fi) Thanks! -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Export objs from an external Makefile?
On Fri, Oct 12, 2001 at 10:14:38AM +1000, Keith Owens wrote: On Thu, 11 Oct 2001 16:57:34 -0700, Tom Rini [EMAIL PROTECTED] wrote: On Fri, Oct 12, 2001 at 09:42:05AM +1000, Keith Owens wrote: On Thu, 11 Oct 2001 09:35:32 -0700, Tom Rini [EMAIL PROTECTED] wrote: Hey all. How do you do the 'export-objs' bits in a kernel module that's outside of the kernel? Thanks.. Compile with -DMODULE -DEXPORT_SYMTAB. If the kernel has modversions, add -DMODVERSIONS -include $(HPATH)/linux/modversions.h. The safest way is to compile a module in the kernel that exports the objects then copy the command, substituting the file names. I think I managed to get things right. I added -DEXPORT_SYMTAB to the default flags and added: CFLAGS_EXTRA += $(shell if [ -f $(KERNEL_HEADERS)/linux/modversions.h ]; \ then echo -include \ $(KERNEL_HEADERS)/linux/modversions.h; fi) You need -DMODVERSIONS as well. D'oh... Testing for the presence of modversions.h will not work in kbuild 2.5, that file is always created with error messages to catch people who include it by hand. OTOH, kbuild 2.5 has support for compiling outside the standard kernel tree so who cares :)? Right. I'm sure some changes will have to be made for external modules once 2.5 is underway... -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Circular deps
Hey all. Will 'circular deps' be a problem with kbuild-2.5? Right now on PPC, we have something like: asm/irq.h: #include asm/ppc4xx.h #define some IRQ bits asm/ppc4xx.h: #include some board files asm/board.h: #include asm/irq.h /* circular, !@#$ */ #define something THIS_IRQ Will this be a problem with kbuild-2.5 as well? -- 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] Circular deps
On Sat, Oct 06, 2001 at 12:27:49PM +1000, Keith Owens wrote: On Fri, 5 Oct 2001 17:19:59 -0700, Tom Rini [EMAIL PROTECTED] wrote: Hey all. Will 'circular deps' be a problem with kbuild-2.5? No. 2.5 uses a 2 layer dependency tree instead of the multi-layer (and possibly circular) tree used in 2.4. I was hoping for as much. Thanks! -- 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: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: Jakob == Jakob ?stergaard [EMAIL PROTECTED] writes: Jakob On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: I think this is a very important point, and one I agree with. I tend to let my distribution handle stuff like python. now, I use RedHat's on-going devel, RawHide. it is not using python2. in fact, since switching to python2 may break old stuff, I don't expect python2 until 8.0. that wont be for 9 months. 90% of RedHat's configuration tools, et al, are written in python1 and they just are not going to change on someone's whim. Jakob 2.6.0 isn't going to happen for at least a year or two. What's Jakob the problem ? Jakob Want 2.5.X ? Get the tools too. Some people grab the latest devel kernels because thats all that works on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. Jakob I'm in no position to push people around, but I think the Jakob whining about CML2 tool requirements is completely unjustified. Jakob If we required that everything worked with GCC 2.7.2 and nmake, Jakob where would we be today ? I'm a lot more worried about CML2 Jakob itself than about the tools it requires :) gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? Jakob Whether CML2 requires python2 or not, the distributions will Jakob change. This is not about Eric pushing something down people's Jakob throats. Tools evolve, and new revisions introduce Jakob incompatibilities, but distributions still follow the Jakob evolution. Nobody ships perl4 today either. The point is that Eric has been trying to push distributions to ship P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote: On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: On Thu, 17 May 2001 03:26:36 -0400, Eric S. Raymond [EMAIL PROTECTED] wrote: Pavel Machek [EMAIL PROTECTED]: And If I want scsi-on-atapi emulation but not vme147_scsi? Help me understand this case, please. What is scsi-on-atapi? Is SCSI on when you enable it? And is it a realistic case for an SBC? SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid layer code but no SCSI hardware drivers. It is a realistic case for an embedded CD-RW appliance. Or alternatively, you want to enable SCSI code, with no hardware driver, because you are going to build pcmcia, which builds the scsi drivers only if CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi card into your pcmcia slot. Both of these 'problems' assume that you can have IDE or PCMCIA on these particular boxes. Does anyone know if that's actually true? What eric is trying to do, can work, if done very carefully, and in very limited cases as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 07, 2001 at 09:31:40PM -0400, Eric S. Raymond wrote: Tom Rini [EMAIL PROTECTED]: [snip] Exactly. In fact we can be more specific -- the Macintoshes in question are the old-fashioned NuBus-based 68k toaster boxes, not the more recent designs with a PCI bus. Relevant stuff in the Configure.help implies that MAC_SCC and MAC_SCSI enable support for the on-board hardware built into those puppies. But Alan's point is a good one. There are _lots_ of cases you can't get away with things like this, unless you get very fine grained. In fact, it would be much eaiser to do this seperately from the kernel. Ie another, possibly/probably _not_ inkernel config tool which asks what machine you have, picks lots of sane defaults and setups a kernel config for you. This is _sort of_ what PPC does right now with the large number of 'default configs' (arch/ppc/configs). You're really talking about a different issue here, autoconfiguration rather than static dependencies. Giacomo Catenazzi is working on that. Only sort-of. There are some cases where you can get away with that. Probably. eg If you ask for PARPORT, on x86 that means yes to PARPORT_PC, always (right?) On other arches (someone brought this up before) it could be PC, it could be something else. My point is there are only some cases where you can get away with asking for serial and knowing the driver. I've given this some thought before, and at least on PPC, you can at best segment off some drivers as depending on family X, but family X doesn't mean you have part Y. The other thing to keep in mind is I'm sure there's lots of unintentionally correct bits. In short, please be very careful when you change a symbol from a question to a derive. You're bound to piss off someone :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
