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-kernel&m=103669658505842&w=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
[kbuild-devel] Re: [PATCH] Have split-include take another argument
On Mon, Nov 11, 2002 at 05:37:10PM -0600, Peter Samuelson wrote:
> [Tom Rini]
> > First, does anyone see any problems with the patch itself?
>
> Well,
>
> > - str_config += sizeof("CONFIG_") - 1;
> > + str_config += strlen(str_split_token);
>
> it does seem a bit inefficient to call strlen() for every single line
> of every single source file. Perhaps today's compilers know that
> strlen() is invariant and has no side effects, but I vote you go ahead
> and optimise it explicitly.
Sounds good, thanks.
--
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] 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 Sun, Oct 27, 2002 at 09:19:27PM +0100, Roman Zippel wrote: > At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of > the new config system. I've got a question / feature request. Right now, CML1 doesn't like something like the following: # Any / all of the following bools can be true. if [ "$CONFIG_BOARD_A" = "y" ]; then define_bool CONFIG_FTR_A y define_bool CONFIG_FTR_B y define_bool CONFIG_FTR_C y fi if [ "$CONFIG_BOARD_B" = "y" ]; then define_bool CONFIG_FTR_A y define_bool CONFIG_FTR_C y define_bool CONFIG_FTR_D y fi 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. Thanks. -- 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
[kbuild-devel] [PATCH 2.5] Make scripts/Configure follow the definition of 'int'
Currently, scripts/Configure has code for the 'int' verb to take a
min/max. This violates the spec described in
Documentation/kbuild/config-language.txt. It also requires that if a
default is outside of +/- 10,000,000 that defaults be provided, or
'config' and 'oldconfig' will get stuck. The following removes the
support for a min/max from scripts/Configure.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= scripts/Configure 1.6 vs edited =
--- 1.6/scripts/Configure Wed Jun 5 17:40:52 2002
+++ edited/scripts/ConfigureTue Sep 24 07:58:59 2002
@@ -415,25 +415,15 @@
#
# int processes an integer argument with optional limits
#
-# int question define default [min max]
+# int question define default
#
function int () {
old=$(eval echo "\${$2}")
def=${old:-$3}
- if [ $# -gt 3 ]; then
- min=$4
- else
- min=-1000# !!
- fi
- if [ $# -gt 4 ]; then
- max=$5
- else
- max=1000 # !!
- fi
rndval $2
while :; do
readln "$1 ($2) [$def] " "$def" "$old"
- if expr \( \( $ans + 0 \) \>= $min \) \& \( $ans \<= $max \) >/dev/null 2>&1
; then
+ if expr "$ans" : '[0-9]*$' > /dev/null; then
define_int "$2" "$ans"
break
else
---
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] scripts/Configure and 'int'
On Tue, Sep 24, 2002 at 10:04:41AM +1000, Greg Banks wrote: > [...catching up on last few week's email...] > > Tom Rini wrote: > > > > Hello. Cufrrently in both 2.4 ad 2.5, scripts/Configure implements > > optional min/max arguments for the 'int' keyword. > > There are two problems however, first being that the spec, as defined in > > Documentation/kbuild/config-language.txt states that the int verb does > > not take range parameters, so this is out of spec. > > Secondly, if one specifies a default value higher than 1000 (or > > lower than -1000) oldconfig/config become horribly unhappy, unless > > the invalid range parameters are included. > > > > So, would anyone object to patches to fix this behavior and any Config > > entries which use it? Thanks. > > I don't think any entries use it, they would turn up as parse errors in gcml2. Ah, that's good to hear. > I think the best way to fix the behaviour is to remove it from Configure > entirely, so that Configure matches the spec. So do I. I'll have patches up shortly. -- 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
[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
[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 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
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
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
[kbuild-devel] Re: kbuild for ppc
On Tue, Apr 23, 2002 at 03:40:19PM +1000, Brendan J Simon wrote: > > Does anyone know if kbuild-2.5-release-1.12 supports the embedded ppc > boards ? > I've managed to configure the 2.4.18-pre8 kernel for a custom board. > "make installable" creates the vmlinux file but the embedded wrapper > isn't created. Correct. At the time the stuff in arch/ppc/boot differed vastly between the PPC trees and kernel.org. But since they're synced up again now, it's time to tackle arch/ppc/boot :) > The arch/ppc/Makefile.in has a "link_subdirs(kernel mm math-emu)" statement. > The build directory (arch/ppc) has the following directories: 8260_io, > kernel, mm, lib, math-emu. > How does the 8260_io and lib directory get built ? I _think_ I test-built an 8260 kernel but I'm not sure. > How can I get the wrapper to build. kbuild-2.4 used the make zImage in > arch/ppc/mbxboot/Makfile for kernel-2.4.0. It is now arch/ppc/boot/mbx > for 2.4.18. It's arch/ppc/boot/simple in 2.4.19-preX, and that's the 'correct' stuff. > If I configured for pmac, how does the build system know to delve into > the arch/ppc/boot/pmac directory ? Well, w/ kbuild-2.4 arch/ppc/boot/Makefile controls all of that with SUBDIR-$(...) statements. -- 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] 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] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 12:35:31PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > Perhaps that wasn't quite the right words. Statement for Statement and
> > no additional restrictions on questions.
>
> Statement for statement is not going to happen, simply because the structure
> of the old and new languages is different.
Strictly stated implication for strictly stated implication?
> What invariant or behavior are you trying to preserve with "no additional
> restrictions"? Most of the additional restrictions are bus guards, so that
> (for example) users won't see EISA questions on a non-EISA system. Is this
> a bad thing?
Well, if there wasn't an EISA guard for CML1, there should't be for CML2
_yet_. Why? It's either an intentional feature (it's actually EISA and
some wierd bus from {arm,ppc,cris,other}) or it's a bug that should be
submitted seperately so someone can pop up and say it's wrong or not.
There's an underlying concern that if it's not a rather strict
translation of the current rules, there's bugs, and people don't want to
fix bugs that don't exist in the current system.
> > > You want the PPC_RTC thing fixed. I'll do that. What else do *you* need?
> >
> > Showing of CONFIG options that don't have a help text, regardless of
> > CONFIG_ADVANCED (or whichever was the guard for that before) if you
> > haven't changed that since the last time someone brought it up.
>
> I've commented out the declaration that sets this guard for 2.3.1.
Good. This should fix one of the real complaints about CML2 being
horrifyling different in questionable ways from CML1.
> --
> http://www.tuxedo.org/~esr/";>Eric S. Raymond
--
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 12:05:45PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > It's not so much the look & feel (which seems to have been copied well > > by now), but policy changes. > > I'm glad you think I got the look and feel OK. If I were bug-for-bug > compatible with the old system, there would hardly be any point, would > there? Perhaps that wasn't quite the right words. Statement for Statement and no additional restrictions on questions. > You want the PPC_RTC thing fixed. I'll do that. What else do *you* need? Showing of CONFIG options that don't have a help text, regardless of CONFIG_ADVANCED (or whichever was the guard for that before) if you haven't changed that since the last time someone brought it up. -- 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
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 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
[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: 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: 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. 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 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
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
[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(CO
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
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] 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
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 . 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 #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] 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: .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 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 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 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 Wed, Dec 19, 2001 at 03:02:21PM -0700, Tom Rini wrote:
> 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 :)
Okay, I think I spoke abit too soon (And had too many other kludges in
at the time). Right now arch/ppc/Makefile.defs.config has:
# 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
And arch/ppc/kernel/Makefile.in:
select($(arch_head))
uses_asm_offsets($(arch_head))
Which should work, yes? But when I run make I get:
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
CPP arch/ppc/vmlinux.lds.i
make[1]: *** No rule to make target `arch/ppc/kernel/head.o', needed by
`init/compile.h'. Stop.
Which is horribly bogus, since CONFIG_8xx is set. But ppc/.tmp_env has:
export 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'
KBUILD_WRITABLE='y' arch_head='arch/ppc/kernel/head.o'
--
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_CRITICAL?
Hey all. Since I finally got one of my PPC board booting (with some help from kbuild-2.4 for the vmlinux->zImage part), I was wondering what all needs to be done for KBUILD_CRITICAL. I've got KBUILD_CRITICAL_PPC defined, but I don't see where KBUILD_CRITICAL_ARCH_X86 is being used. So is KBUILD_CRITICAL functional yet, or something coming soon? 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: 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] 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: .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] 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 , 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] 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 , 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 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
[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
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 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] .tmp_targets failing?
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.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] 'distclean' on kbuild-2.5?
Where'd the 'distclean' target go in kbuild-2.5? Shouldn't it be at least a synonym for mrproper now? -- 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 1.9.9 ia64
On Tue, Dec 18, 2001 at 10:51:55AM +1100, Keith Owens wrote: > On Mon, 17 Dec 2001 11:20:11 -0700, > Tom Rini <[EMAIL PROTECTED]> wrote: > >On Mon, Dec 17, 2001 at 10:03:11PM +1100, Keith Owens wrote: > >> I can live with that - just. The help text for each of the build > >> formats must be duplicated, even though VMLINUZ_X86 is _identical_ to > >> VMLINUZ_IA64. People who read the rules might think that VMLINUZ has > >> different formats on the two architectures. I see lots of comments in > >> my coding future ... > > > >But that's rather nice when BZIMAGE_M68K means a bzip2'ed file and > >BZIMAGE_X86 means a big zImage. :) > > The same name meaning two different formats is a design error. User > says "I have a bzImage file", does that mean they have the correct > format for the architecture (good) or they copied the bzImage file from > i386 to m68k (bad) and now they wonder why it will not boot? The problem is nothing is defined anywhere. :) As it is, lots of newbies think 'bzImage' is a bzip2'ed zImage of sorts. -- 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
[kbuild-devel] .tmp_targets failing?
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: # Must extract delayed knowledge about targets before phase 5, otherwise # a few # targets are not marked as such and no old commands are extracted. $(KBUILD_OBJTREE).tmp_targets: $(KBUILD_OBJTREE).tmp_filelist.bin \ $(KBUILD_OBJTREE).tmp_filelist.txt \ $(KBUILD_OBJTREE).tmp_database \ $(KBUILD_OBJTREE).tmp_global_makefile_in.2 \ $(scripts_objtree)pp_makefile2 to be just @/bin/true, I get to the point of kbuild-2.5 telling me there's no rule to make target 'installable'. Right now I just cp'ed the x86 one, but changed it to define_bool CONFIG_VMLINUX (then VMLINUZ, same problem). I can email the Makefile.in's privatly, but they look an awful lot like the ones I had for ~2.4.8, if anyone has those still :) -- 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 1.9.9 ia64
On Mon, Dec 17, 2001 at 10:03:11PM +1100, Keith Owens wrote: > On Mon, 17 Dec 2001 02:35:52 -0500, > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > >The right answer looks like this: > >private VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86 > >choices kernel_format_x86 # The format that the kernel is to be compiled in > > VMLINUX_X86 VMLINUZ_X86 BZIMAGE_X86 ZIMAGE_X86 default BZIMAGE_X86 > >private VMLINUX_IA64 VMLINUZ_IA64 > >choices kernel_format_ia64 # The format that the kernel is to be compiled in > > VMLINUX_IA64 VMLINUZ_IA64 default VMLINUZ_IA64 > >derive VMLINUX from VMLINUX_X86 or VMLINUX_IA64 > >derive VMLINUZ from VMLINUZ_Z86 or VMLINUZ_IA64 > >derive BZIMAGE from BZIMAGE_X86 > >derive ZIMAGE from ZIMAGE_X86 > > I can live with that - just. The help text for each of the build > formats must be duplicated, even though VMLINUZ_X86 is _identical_ to > VMLINUZ_IA64. People who read the rules might think that VMLINUZ has > different formats on the two architectures. I see lots of comments in > my coding future ... But that's rather nice when BZIMAGE_M68K means a bzip2'ed file and BZIMAGE_X86 means a big zImage. :) -- 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 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 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 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] 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] (no subject)
On Fri, Dec 07, 2001 at 03:36:13PM +1100, Keith Owens wrote: > On Thu, 6 Dec 2001 21:30:59 -0700, > Tom Rini <[EMAIL PROTECTED]> wrote: > >On Fri, Dec 07, 2001 at 03:17:53PM +1100, Keith Owens wrote: > >> 2.5.2-pre1 Add the kbuild 2.5 and CML2 code, still using > >> Makefile-2.5, supporting both CML1 and CML2. > >> i386, sparc, sparc64 can use either kbuild 2.4 or 2.5, > >> 2.5 is recommended. > >> ia64 can only use kbuild 2.5. > >> Other architectures continue to use kbuild 2.4. > >> Wait 24 hours for any major problems then - > > > >Could we wait longer here? Maybe 48 or 72 to give other arches time to > >convert and attempt to sync again? Or at least show it to Keith so he > >can try and sync it up. :) > > We will not get all architectures converted in 48 hours or even 72. > kbuild 2.5 has been available for months and only i386, ia64, sparc32 > (I did all those) and sparc64 (Ben Collins) have been converted. Alpha > is in progress. Unconverted architectures stay on 2.5.2-pre1 until > they do the conversion, but there is no need to hold up everybody else. I think at least part of it is a time thing. It's not official so it's not on the urgent to do list. Once it gets in I can imagine other people picking it up again. I know rmk mentioned he played with it, 6 months ago. Which is about when I played with PPC too. I imagine once it gets in other people/arches will start to try too, and probably have a few more suggestions for things that i386/ia64/sparc* haven't run into. -- 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] (no subject)
On Fri, Dec 07, 2001 at 03:17:53PM +1100, Keith Owens wrote: > Linus, the time has come to convert the 2.5 kernel to kbuild 2.5. I > want to do this in separate steps to make it easier for architectures > that have not been converted yet. > > 2.5.1 Semi-stable kernel, after bio is working. > > 2.5.2-pre1 Add the kbuild 2.5 and CML2 code, still using > Makefile-2.5, supporting both CML1 and CML2. > i386, sparc, sparc64 can use either kbuild 2.4 or 2.5, > 2.5 is recommended. > ia64 can only use kbuild 2.5. > Other architectures continue to use kbuild 2.4. > Wait 24 hours for any major problems then - Could we wait longer here? Maybe 48 or 72 to give other arches time to convert and attempt to sync again? Or at least show it to Keith so he can try and sync it up. :) -- 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 Thu, Dec 06, 2001 at 07:57:10PM -0500, Eric S. Raymond wrote: > Rob Landley <[EMAIL PROTECTED]>: > > P.S. Can we seperate "add new subsystem y prime" and "remove old subsystem > > y". LIke the new and old SCSI error handling, which have been in the tree in > > parallel for some time? Did I hear Eric ever suggest removing the old > > configurator for 2.4? Anybody? > > The whole point of putting the new configurator in would be to be able > to drop the old one out. > > But that would be strictly Marcelo's call. It would be up to him to decide > whether the tradeoff were worth it. Yes, but what people are saying (on this part of the thread) is please don't bother Marcelo with it in the first place. All of the main gripes people have don't apply to the current unstable tree, but most certainly do to the current stable one. -- 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: Switching CML2 back to python1.5x min.
On Tue, Dec 04, 2001 at 06:29:19PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > Getting ncurses and python1.5.x to work is painful, or ncurses + (python > > 1.5.x || python 2.x) is painful? > > All of the above. Besides, the whining about 2.0 is just a displacement. > If I "fix" that, they'll just bitch about sometging else. It would be a lot harder tho. I'm pretty sure any semi-recent disto has at least python 1.5.x. Would it be hard to die at runtime if 1.5.x && ncursea re to be used (assuming the rest is okish). -- 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: Switching CML2 back to python1.5x min.
On Tue, Dec 04, 2001 at 01:48:13PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > I think one of the large arguments against CML2 right now is that it > > needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the > > begining, 1.5.x was used but then switched to 2.0 because it allowed for > > a lot of code to be dropped. > > > > Eric, would it be not-too-painful to either go back to 1.5.x minimum, or > > could we do a runtime check for 2.x and either do the extra things for > > 1.5 or not, depending (not sure if that's worth the bother). This would > > allow a lot more distros already out there to just work. > > There's a problem. It's called ncurses. This might be doable but it > would be very, very painful. Getting ncurses and python1.5.x to work is painful, or ncurses + (python 1.5.x || python 2.x) is painful? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Switching CML2 back to python1.5x min.
I think one of the large arguments against CML2 right now is that it needs Python 2.0+ to work, instead of 1.5.x. IIRC, back in the begining, 1.5.x was used but then switched to 2.0 because it allowed for a lot of code to be dropped. Eric, would it be not-too-painful to either go back to 1.5.x minimum, or could we do a runtime check for 2.x and either do the extra things for 1.5 or not, depending (not sure if that's worth the bother). This would allow a lot more distros already out there to just work. -- 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] Converting the 2.5 kernel to kbuild 2.5
On Tue, Dec 04, 2001 at 06:21:15PM +, Alan Cox wrote: > > make bzlilo modules modules_install: it would be a simble > > make install: (and you configure with CML1/CML2 what install > > means). > > How does it handle that when install means different things on each box of > a set of them NFS sharing the kernel tree. This is a real world example I'd guess you can change the module install path, and re-run 'install' without having anything rebuilt. Admiditly a bit worse off than INSTALL_MOD_PATH=/nfs/boxA. Or set the install paths to .../kernel-XXX/, tar and untar. Or if /usr/local/src/linux is NFS'ed, and you're installing per box, I don't get it. Wouldn't you always install modules into /lib/modules/XXX ? -- 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: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 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] 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 02:48:50PM -0500, Eric S. Raymond wrote:
> Tom Rini <[EMAIL PROTECTED]>:
> > On Thu, Nov 29, 2001 at 02:20:05PM -0500, Eric S. Raymond wrote:
> > > Tom Rini <[EMAIL PROTECTED]>:
> > > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or
> > > > arch/$(ARCH)/boot/rules.cml ?
> > >
> > > Nothing. But if they aren't single declarations, what's going to
> > > *keep* them there?
> >
> > What? If the arch maintainer decides to move them, that's their
> > problem. I can't really think of a good reason. If you really want to
> > enforce a single common spot for 'em, make it a policy thing or at least
> > strongly recommended.
> >
> > But I also don't see what the problem is anyhow. What are you worried
> > might happen?
>
> Suppose we have split declarations for derivations or defaults of
> symbols that are shared across architectures. It would then be
> locally convenient for configuration maintainers to move these
> declarations from the top-level rules.cml file piecemeal to rules
> files in different arch subtrees, or elsewhere.
So say do it in arch/$(ARCH)/.../rules.cml, yes?
> The problem is that it then becomes globally difficult for someone
> reading the rulebase to know what the derivation or default behavior
> of a symbol actually is.
But there is no global 'default'.
> Different pieces of the behavior could be
> scattered all through the rulebase. Even with cross-referencing tools
> (which I have written and tested and use regularly for
> sanity-checking) the effort involved in assembling and integrating
> that picture could be significant. (It already is for the one case
> where supporting split declarations was unavoidable, which is
> visibility predicates.)
True, but these common symbols have architecture-specific meanings
anyhow. As a general rule what your saying makes sense. Like for
CONFIG_SERIAL_CONSOLE, all of the gunk surrounding that should be in one
place. But in this case what 'CONFIG_ZIMAGE' means even varries on
different arches. Aside from it being gzip'ed kernel + bits you can't
really assume anything.
> John Cowan thinks I'm unduly influenced by having had to maintain the
> rulebase all by myself up to now. He's half-right; I've got battle
> scars, yes indeed I do. The last thing I want to do is casually
> create a maintainability problem for anybody who will need to take a
> global view of the config rules in the future. Like...say...Linus?
I certainly hope Linus won't have to know nearly as much about all of
the rule files as you do, or ever really want to for that matter. I
still argue that if all of the derivations of
CONFIG_{ZIMAGE,BZIMAGE,VMLINUX,VMLINUZ,et al} are in
arch/$(ARCH)/boot/rules.cml, as a policy and logic thing, it wouldn't
matter. I can't see anyone wanting to have additional rule-files in
subdirectories (I plan on asking about 'em in 1 rule file :)).
--
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 02:20:05PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or > > arch/$(ARCH)/boot/rules.cml ? > > Nothing. But if they aren't single declarations, what's going to > *keep* them there? What? If the arch maintainer decides to move them, that's their problem. I can't really think of a good reason. If you really want to enforce a single common spot for 'em, make it a policy thing or at least strongly recommended. But I also don't see what the problem is anyhow. What are you worried might happen? -- 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 02:06:40PM -0500, Eric S. Raymond wrote: > Tom Rini <[EMAIL PROTECTED]>: > > > 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? > > It's the human side I'm primarily worried about. Then what's wrong with putting these in arch/$(ARCH)/rules.cml, or arch/$(ARCH)/boot/rules.cml ? -- 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] 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? > -- > http://www.tuxedo.org/~esr/";>Eric S. Raymond > > 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 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. > -- > http://www.tuxedo.org/~esr/";>Eric S. Raymond > > "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 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] 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] 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] 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] 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
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
[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 #define some IRQ bits asm/ppc4xx.h: #include some board files asm/board.h: #include /* 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
[kbuild-devel] Re: Recurse into subdirs?
On Fri, Jun 29, 2001 at 10:57:35PM -0500, Peter Samuelson wrote: > > [Peter Samuelson] > > > Good point. OK, add the following line: > > > > > > subdir- += $(bootdirs-y) $(bootdirs-n) $(bootdirs-) > > [Tom Rini] > > Yes, but is there any compelling reason not to just use subdir- to > > start with? > > Having to manually maintain either (a) which subdirs have valid zImage > targets or (b) which do not. Your initial conversion had a > $(filter-out) statement to implement (b). Well, yes. But the dirs which don't are also always the same. And that may also change :) Thanks for your help. -- 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: Recurse into subdirs?
On Fri, Jun 29, 2001 at 08:47:47PM -0500, Peter Samuelson wrote: > > [Peter Samuelson] > > > bootdirs-$(CONFIG_FOO) += foo > > > bootdirs-$(CONFIG_BAR) += bar > [...] > > > The point here is that you don't use $(subdir-y) for the sub-arch boot > > > dirs. > > [Tom Rini] > > Yes, but I want to use subdir- so that deps get done and handled automagically. > > Good point. OK, add the following line: > > subdir- += $(bootdirs-y) $(bootdirs-n) $(bootdirs-) Yes, but is there any compelling reason not to just use subdir- to start with? -- 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: Recurse into subdirs?
On Fri, Jun 29, 2001 at 08:56:35PM -0500, Peter Samuelson wrote: > > [Peter Samuelson] > > utils-$(CONFIG_FOO) += fooboot > > utils-$(CONFIG_BAR) += barboot bazboot > > > > bootdirs-$(CONFIG_FOO) += foo > > bootdirs-$(CONFIG_BAR) += bar > > > > # Targets for booting > > BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd > > $(BOOT_TARGETS): sImage vmapus images/vmlinux.gz > > $(MAKE) -C utils $(utils-y) > > for d in $(bootdirs-y); do $(MAKE) -C $$d $@; done > > I just noticed -- if bootdirs-y is empty, this will fail with a syntax > error. Likewise, if utils-y is empty it will do the Wrong Thing. I > don't know if either is possible, but if so: Well, the utils problem shouldn't exist. I do: makeutils: $(MAKE) -C utils $(tools-y) Which should do nothing, since the utils dir Makefile has: all: dummy The other one shouldn't exist, because there's always at least one dir. -- 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: Recurse into subdirs?
On Fri, Jun 29, 2001 at 07:26:57PM -0500, Peter Samuelson wrote: > utils-$(CONFIG_FOO) += fooboot > utils-$(CONFIG_BAR) += barboot bazboot > > bootdirs-$(CONFIG_FOO) += foo > bootdirs-$(CONFIG_BAR) += bar > > # Targets for booting > BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd > $(BOOT_TARGETS): sImage vmapus images/vmlinux.gz > $(MAKE) -C utils $(utils-y) > for d in $(bootdirs-y); do $(MAKE) -C $$d $@; done > > The point here is that you don't use $(subdir-y) for the sub-arch boot > dirs. Yes, but I want to use subdir- so that deps get done and handled automagically. But this does work, thanks! > If you can assume that CONFIG_FOO and CONFIG_BAR are mutually > exclusive, you don't need the for loop. Yes, but CONFIG_FOO can (and does) have multiple dirs it needs to go into. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Recurse into subdirs?
Hello all. I've got a question about doing subdirs 'properly'. First, what I'm trying to do is cleanup arch/ppc/boot/Makefile. In Linus' tree, it's not too bad. But there's a bunch of changes pending, which end up leaving the tree looking like this: # Targets for booting BOOT_TARGETS = zImage zImage.initrd znetboot znetboot.initrd $(BOOT_TARGETS): sImage vmapus images/vmlinux.gz ifdef CONFIG_FOO $(MAKE) -C utils fooboot $(MAKE) -C foo $@ endif ifdef CONFIG_BAR $(MAKE) -C utils barboot bazboot $(MAKE) -C bar $@ endif Which has problems, and looks bad. I've got it currently working with subdir-$(CONFIG_FOO) += foo tools-$(CONFIG_FOO) := fooboot # := since you can only have 1 set And a rule for making tools. But, to get the targets working I had to do: # These are dirs we don't want to go into on BOOT_TARGETS NONBOOT := lib images common # These are the subdirs we want to use BOOTDIRS= $(filter-out $(NONBOOT), $(subdir-y)) subdir-zImage-list = $(sort $(patsubst %,_bdzI_%,$(BOOTDIRS))) $(subdir-zImage-list) : dummy $(MAKE) -C $(patsubst _bdzI_%,%,$@) zImage zImage: sImage ... maketools $(subdir-zImage-list) For each of the targets. Is there a nicer way to do this? Thanks. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://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
[kbuild-devel] Re: CML2 design philosophy heads-up
On Sun, May 06, 2001 at 01:58:49PM +0100, Alan Cox wrote: > > # These were separate questions in CML1 > > derive MAC_SCC from MAC & SERIAL > > derive MAC_SCSI from MAC & SCSI > > derive SUN3_SCSI from (SUN3 | SUN3X) & SCSI > > Not all Mac's use the SCC if they have serial > Not all Mac's use the same SCSI controller Yes, but in this case 'MAC' means m68k mac, which this _might_ be valid, but I never did get Linux up and running on the m68ks I had.. 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). -- 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: [upatch] lib/Makefile
On Mon, Apr 23, 2001 at 05:16:24PM -0500, Peter Samuelson wrote: > Introduced in 2.4.4pre4, I believe. $(export-objs) need not be > conditional, and the if statement was not really correct either, > although in this case it probably worked. Er, are you sure changing the test for !"nn" is correct here? I _think_ at least that is intentional and correct (since you can have one on but not the other). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
