Re: [kbuild-devel] Re: CML2 1.0.0 release announcement
I like mconfig, but I like CML2 better. My primary reason is that ESR has more time to work on CML2 than I do on mconfig. And speed problems are often the easiest problems to solve. Eric did some performance analysis. If I recall correctly, all but 1 or 2 seconds of CML2's runtime is in the parser. He has rewritten the parser once. Maybe someone needs to rewrite it again, maybe propagate some changes into the language spec to make it easier to parse, maybe rewrite from Python to C. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML2 1.0.0 release announcement
I like mconfig, but I like CML2 better. My primary reason is that ESR has more time to work on CML2 than I do on mconfig. And speed problems are often the easiest problems to solve. Eric did some performance analysis. If I recall correctly, all but 1 or 2 seconds of CML2's runtime is in the parser. He has rewritten the parser once. Maybe someone needs to rewrite it again, maybe propagate some changes into the language spec to make it easier to parse, maybe rewrite from Python to C. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] CML1 cleanup patch, take 3
Eric Raymond writes: > Bjorn Wesen <[EMAIL PROTECTED]> informs me that the CRIS symbol bugs > will be fixed in the next CRIS port update. Hey, there's even a spec which says that config symbols have to look like CONFIG_*: # Documentation/kbuild/config-language.txt A /symbol/ is a single unquoted word. A symbol must have a name of the form CONFIG_*. scripts/mkdep.c relies on this convention in order to generate dependencies on individual CONFIG_* symbols instead of making one massive dependency on include/linux/autoconf.h. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] CML1 cleanup patch, take 3
Eric Raymond writes: Bjorn Wesen [EMAIL PROTECTED] informs me that the CRIS symbol bugs will be fixed in the next CRIS port update. Hey, there's even a spec which says that config symbols have to look like CONFIG_*: # Documentation/kbuild/config-language.txt A /symbol/ is a single unquoted word. A symbol must have a name of the form CONFIG_*. scripts/mkdep.c relies on this convention in order to generate dependencies on individual CONFIG_* symbols instead of making one massive dependency on include/linux/autoconf.h. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML1 cleanup patch
Eric Raymond writes: > (1) 19 of the 39 changes fix things that are outright bugs even in CML1. > These should not be allowed to persist in the stable branch. I think that things that are bugs in CML1, on its own terms, are worth fixing in 2.4. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kbuild-devel] Re: CML1 cleanup patch
Eric Raymond writes: (1) 19 of the 39 changes fix things that are outright bugs even in CML1. These should not be allowed to persist in the stable branch. I think that things that are bugs in CML1, on its own terms, are worth fixing in 2.4. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Make errors in 2.4 drivers/acpi, recursive CFLAGS
I wonder if Gnu Make 3.78.1 has the same problem? I know of one bug in 3.78.1 where $(if ...) statements which have an "else" clause screw up the parsing of the "else" clause. But there shouldn't be any $(if ...) constructs in the kernel Makefiles. I guess we'll either have to find the problem and work around it, or deprecate Gnu Make 3.78. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Make errors in 2.4 drivers/acpi, recursive CFLAGS
I wonder if Gnu Make 3.78.1 has the same problem? I know of one bug in 3.78.1 where $(if ...) statements which have an "else" clause screw up the parsing of the "else" clause. But there shouldn't be any $(if ...) constructs in the kernel Makefiles. I guess we'll either have to find the problem and work around it, or deprecate Gnu Make 3.78. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0-prerelease drm and modversions
mec> This looks good to me. It's missing a dependency though. If foo-mod.c mec> exists, and someone edits or patches foo.c, then foo-mod.c needs to be mec> re-created. Doh. It's a symlink, not a copy. It never needs updating. I'll go debug a Hangman program or something. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0-prerelease drm and modversions
Keith Owens writes: kaos> drivers/char/drm/Makefile is breaking the Makefile rules. It builds kaos> drmlib.a and expects to link that library into both the kernel and into kaos> modules. Ah, shit. kaos> The kernel makefile system assumes that everything is either kernel or kaos> module, not both. The components in drmlib.a get compiled for kernel kaos> only, when used in a module they are missing the symbol versions. I agree with Keith. The kernel version is going to get compiled, and then the module version is going to get compiled with different compilation flags: -DMODULE. The two versions are always going to fight. kaos> +$(patsubst %.o,%.c,$(lib-objs-mod)): kaos> + @ln -sf $(subst -mod,,$@) $@ kaos> + This looks good to me. It's missing a dependency though. If foo-mod.c exists, and someone edits or patches foo.c, then foo-mod.c needs to be re-created. Keith, what do you think of this: source-objs-mod := $(patsubst %-mod.o,%-mod.c,$(lib-objs-mod)) $(source-objs-mod): $(patsubst %-mod.c,%.c,$(source-objs-mod)) ln -sf $(patsubst %-mod.c,%.c,$@) $@ It suffers from the thundering herd problem (each *-mod.c depend on all *.c files) but I think it's correct. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0-prerelease drm and modversions
Keith Owens writes: kaos drivers/char/drm/Makefile is breaking the Makefile rules. It builds kaos drmlib.a and expects to link that library into both the kernel and into kaos modules. Ah, shit. kaos The kernel makefile system assumes that everything is either kernel or kaos module, not both. The components in drmlib.a get compiled for kernel kaos only, when used in a module they are missing the symbol versions. I agree with Keith. The kernel version is going to get compiled, and then the module version is going to get compiled with different compilation flags: -DMODULE. The two versions are always going to fight. kaos +$(patsubst %.o,%.c,$(lib-objs-mod)): kaos + @ln -sf $(subst -mod,,$@) $@ kaos + This looks good to me. It's missing a dependency though. If foo-mod.c exists, and someone edits or patches foo.c, then foo-mod.c needs to be re-created. Keith, what do you think of this: source-objs-mod := $(patsubst %-mod.o,%-mod.c,$(lib-objs-mod)) $(source-objs-mod): $(patsubst %-mod.c,%.c,$(source-objs-mod)) ln -sf $(patsubst %-mod.c,%.c,$@) $@ It suffers from the thundering herd problem (each *-mod.c depend on all *.c files) but I think it's correct. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.4.0-prerelease drm and modversions
mec This looks good to me. It's missing a dependency though. If foo-mod.c mec exists, and someone edits or patches foo.c, then foo-mod.c needs to be mec re-created. Doh. It's a symlink, not a copy. It never needs updating. I'll go debug a Hangman program or something. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] How do we handle autoconfiguration?
esr> # PROCESSOR is string valued; we capture stdout from the probe
esr> derive PROCESSOR from "myprobe1.sh"
esr>
esr> # FOOFEATURE is boolean; we look at the return status from myprobe2.py
esr> derive FOOFEATURE from "myprobe2.py"
I think this is cool.
esr> (kbuild people, this is one reason I want ifdefs gone from the
esr> makefiles. The autoconfigurator, whether it's Giacomo's or not,
esr> should be able to pass FOO=n to tell CML2 that a given feature is
esr> definitely not present.)
Yeah, we have to make an essential transition from 3-valued logic
("y"/"m"/"n" in some contexts and "y"/"m"/NULL in other contexts) to
4-valued logic ("y"/"m"/"n"/NULL).
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] How do we handle autoconfiguration?
esr # PROCESSOR is string valued; we capture stdout from the probe
esr derive PROCESSOR from "myprobe1.sh"
esr
esr # FOOFEATURE is boolean; we look at the return status from myprobe2.py
esr derive FOOFEATURE from "myprobe2.py"
I think this is cool.
esr (kbuild people, this is one reason I want ifdefs gone from the
esr makefiles. The autoconfigurator, whether it's Giacomo's or not,
esr should be able to pass FOO=n to tell CML2 that a given feature is
esr definitely not present.)
Yeah, we have to make an essential transition from 3-valued logic
("y"/"m"/"n" in some contexts and "y"/"m"/NULL in other contexts) to
4-valued logic ("y"/"m"/"n"/NULL).
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
> Jakub Jelinek claims to have fixed this particular bug in the last week > or so, although I have not downloaded and compiled recent CVS to verify > this. I have a compiler from gcc.gnu.org's CVS tree that's only a few days old, so I can verify Jakub's claim. It Works For Me (tm). There is a considerable amount of engineering and testing and releasology and distribution between "CVS compiler" and "production compiler for kernel builds" though. > and according to Jeff Law, this case is *not* fixed yet. My compiler behaves as Jeff says. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: beware of dead string constants
Jakub Jelinek claims to have fixed this particular bug in the last week or so, although I have not downloaded and compiled recent CVS to verify this. I have a compiler from gcc.gnu.org's CVS tree that's only a few days old, so I can verify Jakub's claim. It Works For Me (tm). There is a considerable amount of engineering and testing and releasology and distribution between "CVS compiler" and "production compiler for kernel builds" though. and according to Jeff Law, this case is *not* fixed yet. My compiler behaves as Jeff says. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] test11pre6: incorrect makefile change
peter> This toplevel Makefile change in 11pre6 is wrong: peter> peter> -$(HOSTCC) $(HOSTCFLAGS) -o scripts/split-include scripts/split-include.c peter> +$(HOSTCC) $(HOSTCFLAGS) -I$(HPATH) -o scripts/split-include scripts/split-include.c Peter is right. $(HOSTCC) must compile and link C programs on the host without reference to any kernel include files. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [KBUILD] test11pre6: incorrect makefile change
peter This toplevel Makefile change in 11pre6 is wrong: peter peter -$(HOSTCC) $(HOSTCFLAGS) -o scripts/split-include scripts/split-include.c peter +$(HOSTCC) $(HOSTCFLAGS) -I$(HPATH) -o scripts/split-include scripts/split-include.c Peter is right. $(HOSTCC) must compile and link C programs on the host without reference to any kernel include files. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre7
Let me see if I have all this straight: (1) Change Rules.make to use "new style" variables as its native form. (1A) Add a "Compat.make" for old style Makefiles, and (1B) Continue to convert all the remaining old style Makefiles. (2) Go with the "export-objs" style of declaring source files that need to be run through genksyms. Files never get built just because they are in $(export-objs); $(export-objs) just determines who gets processed by genksyms at compile time. (3) No LINK_FIRST / LINK_LAST. Whatever is in the Makefile gets linked in that order. We won't use $(sort ...) to eliminate duplicates (we will continue to handle them another way). (4) When a multi is built into the resident kernel, the whole multi goes in, with no splitting into component parts. Is that your plan, Linus? I disagree with (3) because I think that initialization order requirements should be spelled out and documented. But I accept it. Historical note on (4): as Keith said, I had to split up the multi's in order to get the components into the OX_OBJS list. But with a more thorough implementation of (2), this becomes unnecessary. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test10-pre7
Let me see if I have all this straight: (1) Change Rules.make to use "new style" variables as its native form. (1A) Add a "Compat.make" for old style Makefiles, and (1B) Continue to convert all the remaining old style Makefiles. (2) Go with the "export-objs" style of declaring source files that need to be run through genksyms. Files never get built just because they are in $(export-objs); $(export-objs) just determines who gets processed by genksyms at compile time. (3) No LINK_FIRST / LINK_LAST. Whatever is in the Makefile gets linked in that order. We won't use $(sort ...) to eliminate duplicates (we will continue to handle them another way). (4) When a multi is built into the resident kernel, the whole multi goes in, with no splitting into component parts. Is that your plan, Linus? I disagree with (3) because I think that initialization order requirements should be spelled out and documented. But I accept it. Historical note on (4): as Keith said, I had to split up the multi's in order to get the components into the OX_OBJS list. But with a more thorough implementation of (2), this becomes unnecessary. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lvm in 2.4.0-test9pre5
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y. The simple correct way is to use some ugly temporary variables: MD and MMD. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lvm in 2.4.0-test9pre5
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y. The simple correct way is to use some ugly temporary variables: MD and MMD. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Hi Helge, helge> Ability to put one particular controller first solves the boot issues helge> just fine though. Ah, here is a boot option for you: append="scsihosts=imm:advansys:advansys:aha1542" Read this: http://www.torque.net/scsi/scsihosts.html Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Hi Helge, helge Ability to put one particular controller first solves the boot issues helge just fine though. Ah, here is a boot option for you: append="scsihosts=imm:advansys:advansys:aha1542" Read this: http://www.torque.net/scsi/scsihosts.html Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Eric Youngdale writes:
> .initcall.init : { *(.initcall.init1) }
> .initcall.init : { *(.initcall.init2) }
> .initcall.init : { *(.initcall.init) }
I like this idea.
I would add initcall.init8 and initcall.init9 in order to have some
levels after the normal initcalls.
> It isn't as ugly as jumping through millions of hoops to get the Makefiles
> to do it right.
It's about three lines in Rules.make to do link ordering in each
directory.
But the situation in scsi right now requires cross-directory ordering
and that is going to be some ugly hoop-jumping if done in Makefiles.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/f1
Hi Daniel, > tar -cvf /dev/f1 . Take a look at the line before it: tar: tar -cvf /dev/f1 . This goal has been in the net/*/Makefile files a very long time. I see it in linux-0.99.1.tar! My guess is that the original author/user of this little goal liked to back up their work to floppy disk every so often (think about it, they didn't have mature networking in place, so a floppy backup makes a lot of sense). I'll also guess that the original author/user is no longer backing up onto floppies, and no one would mind if someone removed this historic relic. But it's not a 2.4 critical bug so no action for a while. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
torben> core-hosts/i2o-upper. Ok, I understand the problem. Can you elaborate some more on exactly which files go in "core", "hosts", and "upper"? My understanding is: # drivers/scsi scsi-core-files := scsi_mod.o scsi_syms.o scsi-hosts-files := ... everything not in core and upper ... scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o # i2o i2o-files:= %.o I can do this in the top Makefile by declaring lists like the above using $(filter) and $(filter-out). The hard part is going to be defining "scsi-hosts-files" to work properly. I think I will need to add a few more lines to drivers/scsi/Makefile and make one more multi. Or maybe three more multis. But I'm sure I can do it without moving any source files around. torben> The perfect solution would be to remove the link order torben> dependency. Yeah, I agree with Linus: minimizing link order dependencies is the right thing. For the link order dependencies which *do* exist at any point in time, I'd like the Makefiles to have explicit link-ordering declarations with comments on them about why they are needed. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Torben Mathiasen wrote: > I can't seem to find a clean way of getting the drivers outside > "drivers/scsi" to link _after_ the other low-level drivers. Can you characterize the problem in more detail for me? That is, exactly what link order constraints you are trying to obey. I am thinking about this: # Makefile link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o link-last := DRIVERS := \ $(filter $(link-first), $(DRIVERS)) \ $(filter-out $(link-first) $(link-last), $(DRIVERS)) \ $(filter $(link-last), $(DRIVERS)) This is just a preliminary thought. I'd like to know more about the problem. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Torben Mathiasen wrote: I can't seem to find a clean way of getting the drivers outside "drivers/scsi" to link _after_ the other low-level drivers. Can you characterize the problem in more detail for me? That is, exactly what link order constraints you are trying to obey. I am thinking about this: # Makefile link-first := drivers/scsi/foo.o drivers/i2o/%o drivers/scsi/bar.o link-last := DRIVERS := \ $(filter $(link-first), $(DRIVERS)) \ $(filter-out $(link-first) $(link-last), $(DRIVERS)) \ $(filter $(link-last), $(DRIVERS)) This is just a preliminary thought. I'd like to know more about the problem. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
torben core-hosts/i2o-upper. Ok, I understand the problem. Can you elaborate some more on exactly which files go in "core", "hosts", and "upper"? My understanding is: # drivers/scsi scsi-core-files := scsi_mod.o scsi_syms.o scsi-hosts-files := ... everything not in core and upper ... scsi-upper-files := st.o sd_mod.o sr_mod.o sg.o # i2o i2o-files:= %.o I can do this in the top Makefile by declaring lists like the above using $(filter) and $(filter-out). The hard part is going to be defining "scsi-hosts-files" to work properly. I think I will need to add a few more lines to drivers/scsi/Makefile and make one more multi. Or maybe three more multis. But I'm sure I can do it without moving any source files around. torben The perfect solution would be to remove the link order torben dependency. Yeah, I agree with Linus: minimizing link order dependencies is the right thing. For the link order dependencies which *do* exist at any point in time, I'd like the Makefiles to have explicit link-ordering declarations with comments on them about why they are needed. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/f1
Hi Daniel, tar -cvf /dev/f1 . Take a look at the line before it: tar: tar -cvf /dev/f1 . This goal has been in the net/*/Makefile files a very long time. I see it in linux-0.99.1.tar! My guess is that the original author/user of this little goal liked to back up their work to floppy disk every so often (think about it, they didn't have mature networking in place, so a floppy backup makes a lot of sense). I'll also guess that the original author/user is no longer backing up onto floppies, and no one would mind if someone removed this historic relic. But it's not a 2.4 critical bug so no action for a while. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: SCSI scanning
Eric Youngdale writes:
.initcall.init : { *(.initcall.init1) }
.initcall.init : { *(.initcall.init2) }
.initcall.init : { *(.initcall.init) }
I like this idea.
I would add initcall.init8 and initcall.init9 in order to have some
levels after the normal initcalls.
It isn't as ugly as jumping through millions of hoops to get the Makefiles
to do it right.
It's about three lines in Rules.make to do link ordering in each
directory.
But the situation in scsi right now requires cross-directory ordering
and that is going to be some ugly hoop-jumping if done in Makefiles.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning
The exact semantics are: .config: CONFIG_FOO=y# yes CONFIG_FOO=m# module # CONFIG_FOO is not set # no include/linux/autoconf.h: #define CONFIG_FOO 1/* yes */ #undef CONFIG_FOO /* module */ #define CONFIG_FOO_MODULE 1 /* module */ #undef CONFIG_FOO /* no */ So anything in C code that tests for CONFIG_FOO is going to be true if FOO is configured 'yes' and false if FOO is configured 'module'. I think some kernel code suffers from a misapprehension that CONFIG_FOO is enabled for both 'yes' and 'module'. It's only enabled for 'yes'. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_VIDEO_BT848 in 2.4.0-test9pre1 missing
Hi Dietmar, First go to 'General Setup' and make sure that 'PCI support' is turned on. Then go to 'Character Devices' -> 'I2C support'. Turn on both 'I2C support' and 'I2C bit-banging interfaces'. Then go to 'Multimedia devices'. Turn on 'Video for Linux' and enter the 'Video for Linux' submenu. Now you can turn on 'BT848 Video For Linux'. Then go to the Soft Room and pick up the pillow. You will need the pillow later when you bring the beautiful, delicate Ming Vase from the Oriental Room back to the House. Hope this helps, Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bad PATCH] - arch/ppc/config.in for 2.{3,4}.* to get PCI right on G4
> The point is that there's some pollution in arch/ppc/config.in > that doesn't allow a G4 user (for example) to configure a > host of PCI devices. The code in arch/ppc/config.in looks correct to me. Please provide more details on how it "doesn't work here": Are you using 'make config', menuconfig, or xconfig? What menu are you on that gives the bad result? Which PCI devices are you failing to see? Also attach your .config file. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.4.0t8] Rewritten drivers/ide/Makefile
Hi Bartlomiej, > - Moved $(IDE_OBJS) (now $(ide-obj-y)) from MIX_OBJS to MI_OBJS > due the fact that they don't export any symbols (I hope). They don't export any symbols. > - Removed $(LD_RFLAG), I can't find any definition of it in the > kernel source tree and LD docs. WTF it is (was) used for? You are right: 15 places use it, but nobody ever defines it. It's the same in 2.2.17 as well. I believe the intent was to define it as something like "-m elf_i386", so that cross builds would be more likely to work. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: configuring from kernel source directory
> and then I made the soft link to point to the new directory. If you are talking about a soft link named "linux", just completely delete it and reset it to the value that it had when you installed your distribution and then never touch it again. > rm: include/asm: is a directory Instead of "cp -Rr" to copy the directory, use "cp -a". There is a symlink in your source directory and "cp -Rr" is de-referencing it, whereas "cp -a" properly preserves it. Hope this helps, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Darkstar Development Project
Jamie Lokier writes: > .cvsignore Not so fast. Read your .hdepend file, notice which files that it's touching, and then notice that those are real source files (include/linux/*.h and include/asm/*.h). Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] Darkstar Development Project
Jamie Lokier writes: .cvsignore Not so fast. Read your .hdepend file, notice which files that it's touching, and then notice that those are real source files (include/linux/*.h and include/asm/*.h). Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: configuring from kernel source directory
and then I made the soft link to point to the new directory. If you are talking about a soft link named "linux", just completely delete it and reset it to the value that it had when you installed your distribution and then never touch it again. rm: include/asm: is a directory Instead of "cp -Rr" to copy the directory, use "cp -a". There is a symlink in your source directory and "cp -Rr" is de-referencing it, whereas "cp -a" properly preserves it. Hope this helps, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.4.0t8] Rewritten drivers/ide/Makefile
Hi Bartlomiej, - Moved $(IDE_OBJS) (now $(ide-obj-y)) from MIX_OBJS to MI_OBJS due the fact that they don't export any symbols (I hope). They don't export any symbols. - Removed $(LD_RFLAG), I can't find any definition of it in the kernel source tree and LD docs. WTF it is (was) used for? You are right: 15 places use it, but nobody ever defines it. It's the same in 2.2.17 as well. I believe the intent was to define it as something like "-m elf_i386", so that cross builds would be more likely to work. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for scripts/Configure (zImage->bzImage)
> here's a patch so that make oldconfig informs about bzImage etc as all > the other tools already do. Looks good to me. Linus, please apply. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch for scripts/Configure (zImage-bzImage)
here's a patch so that make oldconfig informs about bzImage etc as all the other tools already do. Looks good to me. Linus, please apply. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] for PAS16 functionality for 2.4
> Yepp. These warnings are there becuse of the way the list-style Makefiles > work. You will see lots of them in drivers/net and drivers/scsi, too. Here's a patch. Let me know if it works for you; if it does, I will submit it for 2.4.0. Here is some history: drivers/sound was the first of the list-style Makefiles and has been using lists since the late 2.1.NN series. Originally, drivers/sound/Makefile used $(sort ...) to remove duplicates. In 2.3.14, Linus introduced init sections. This made $(sort ...) unusable for the construction of O_OBJS and OX_OBJS. Today, O_OBJS and OX_OBJS may contain duplicates, and Rules.make is supposed to ignore the duplicates (while still preserving order). The fact that SYMTAB_OBJS causes these warning messages is a bug. I have written documentation on Rules.make and the interface between Rules.make and Makefiles. It's here: ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff Here's a quote: The order of files in $(O_OBJS) and $(OX_OBJS) is significant. All $(OX_OBJS) files come first, in the order listed, followed by all $(O_OBJS) files, in the order listed. Duplicates in the lists are allowed: the first instance will be linked into $(O_TARGET) and succeeding instances will be ignored. (Note: Rules.make may emit warning messages for duplicates, but this is harmless). I would really like to see this documentation in the kernel. I've sent it to Linus three times, and he's ignored it three times. I will try some more after the release of 2.4.0. Anyways ... I'd appreciate it if a couple of people would try this patch so that I can submit it. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" === diff -u -r -N linux-2.4.0-test8/Rules.make linux/Rules.make --- linux-2.4.0-test8/Rules.makeSun Aug 13 12:55:51 2000 +++ linux/Rules.makeSun Sep 10 14:06:02 2000 @@ -190,7 +190,7 @@ # ifdef CONFIG_MODULES -SYMTAB_OBJS = $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS) +SYMTAB_OBJS := $(sort $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS)) ifdef CONFIG_MODVERSIONS ifneq "$(strip $(SYMTAB_OBJS))" "" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
OK, I give in, I'll post some opinions in this advocacy-like thread. One of the original connotations of "hacker" was someone who made furniture with an axe. There is a difference between a debugger and a compiler. A compiler never substitutes for understanding. In fact, I gain more understanding from reading C source code than I would from reading handcrafted machine code or handcrafted assembly code. Lastly, I believe Linus has said two things: (1) he prefers to work with people who deeply understand the part of Linux that they work on, and (2) he believes that an integrated kernel debugger would be detrimental to (1). Rather than discussing what he's said, I ask: OK, if an integrated kernel debugger is inimical to developing more gurus, what contributions would Linus welcome? More documentation, so that more people can understand more deeply? Cleanup patches, to reduce the complexity that people have to wade through? Linus already seems very friendly to such patches (except when he's trying to push out a stable release). More commentary with submitted patches? Russ Nelson used to write linux kernel patch summaries, and so did I. It would be a lot easier if the people who wrote the patches wrote that commentary, and if it were kept with the patches or near the patches. A source control system so that curious people could do the equivalent of "cvs annotate" and figure out who wrote particular pieces? Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] for PAS16 functionality for 2.4
Yepp. These warnings are there becuse of the way the list-style Makefiles work. You will see lots of them in drivers/net and drivers/scsi, too. Here's a patch. Let me know if it works for you; if it does, I will submit it for 2.4.0. Here is some history: drivers/sound was the first of the list-style Makefiles and has been using lists since the late 2.1.NN series. Originally, drivers/sound/Makefile used $(sort ...) to remove duplicates. In 2.3.14, Linus introduced init sections. This made $(sort ...) unusable for the construction of O_OBJS and OX_OBJS. Today, O_OBJS and OX_OBJS may contain duplicates, and Rules.make is supposed to ignore the duplicates (while still preserving order). The fact that SYMTAB_OBJS causes these warning messages is a bug. I have written documentation on Rules.make and the interface between Rules.make and Makefiles. It's here: ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff Here's a quote: The order of files in $(O_OBJS) and $(OX_OBJS) is significant. All $(OX_OBJS) files come first, in the order listed, followed by all $(O_OBJS) files, in the order listed. Duplicates in the lists are allowed: the first instance will be linked into $(O_TARGET) and succeeding instances will be ignored. (Note: Rules.make may emit warning messages for duplicates, but this is harmless). I would really like to see this documentation in the kernel. I've sent it to Linus three times, and he's ignored it three times. I will try some more after the release of 2.4.0. Anyways ... I'd appreciate it if a couple of people would try this patch so that I can submit it. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" === diff -u -r -N linux-2.4.0-test8/Rules.make linux/Rules.make --- linux-2.4.0-test8/Rules.makeSun Aug 13 12:55:51 2000 +++ linux/Rules.makeSun Sep 10 14:06:02 2000 @@ -190,7 +190,7 @@ # ifdef CONFIG_MODULES -SYMTAB_OBJS = $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS) +SYMTAB_OBJS := $(sort $(LX_OBJS) $(OX_OBJS) $(MX_OBJS) $(MIX_OBJS)) ifdef CONFIG_MODVERSIONS ifneq "$(strip $(SYMTAB_OBJS))" "" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
> There are people today that refuse to use computers for writeing, > and they have good arguments, ... Harken back to David Miller, who wrote about occupying his hands with something to keep them the hell off the keyboard while he is meditating on a screen full of code. One of my debugging tools is a printer. I print out bunches of source code and trace files and then I go to a room *without* any computers in it and I read for a while. And I still write a lot of source code with pen and paper. Michael Elizabeth Chastain <mailto:[EMAIL PROTECTED]> "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
There are people today that refuse to use computers for writeing, and they have good arguments, ... Harken back to David Miller, who wrote about occupying his hands with something to keep them the hell off the keyboard while he is meditating on a screen full of code. One of my debugging tools is a printer. I print out bunches of source code and trace files and then I go to a room *without* any computers in it and I read for a while. And I still write a lot of source code with pen and paper. Michael Elizabeth Chastain mailto:[EMAIL PROTECTED] "love without fear" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
> Yeah. Long transition, plus user education (which never works, dontcha > know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). mec> I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to mec> be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. peter> Am I being obtuse? What is the functional difference? Doh, I am thinking in the wrong language again! "CONFIG_BAR - 0" works when $CONFIG_BAR might expand to either "" or "1". But that's not what happens in 2.4.0 and it's not what happens under Al Viro's proposal. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> And how much did RedHat pay you to do it? Legitimate question. Answer: zero. I wrote it long before I started working for Red Hat. > Oh, I know more than you think I do. No, judging by your posts, you don't. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In the .config file, the problem is that the Makefiles source .config and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances of this in 2.4.0-test-7. In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S) files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH) tests. There are about 8000 instances of this in 2.4.0-test-7. Even worse, any third-party module source is likely to contain the same "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will silently break all of them. I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> However, NO ONE has taken the time (I'm talking weeks of doing nothing > but screwing with Makefiles) to completely rewrite the build system. I have done exactly that. And I gave you the URL. You want to read it, or you want to keep whining that "NO ONE" is doing the work I am pointing you directly to? > What's the point in making processors faster if everyone just > wastes the increase being "correct and simple"? I've also benchmarked my Makefiles against the stock kernel Makefiles. The "correct and simple" Makefiles run in 1/2 the time. Honestly, it's like talking to a wall here. Rick, you don't know what you're talking about, and you show too much unwillingness to learn. I'm not interested in your prejudices any more. *plonk* Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> Well, there's butt-loads of ugly Makefile shit all over the place. It > isn't going away. Some of it went away when Keith Owens rewrote modules-install. More of it went away between 2.2 and 2.4. Check out drivers/net/Makefile or drivers/scsi/Makefile or lots of other Makefiles, for instance. They are 1/3 the size they used to be. Even more of it's going away in 2.5. Here's my contribution to making it go away: ftp://ftp.shout.net/pub/users/mec/kbuild/dancing-makefiles-2.3.26 ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff Where is yours? > Yes and no. You can only insmod _one_ serial.o so the name does have > to be unique at the time it's loaded. True. But the Makefiles are no longer part of this problem. > (BTW, the current modutils (2.3.15) won't see all the modules from a > modules_install.) Oh? That would be a bug. Which modules does it fail to see? > From an efficiency standpoint, one file per directory is a hideous waste > of both filesystem space (one inode and one block) and system resources > (file access times, dcache, et. al.) So, go benchmark "insmods per second". I want to see a %age from some controlled test where the only differences are the module arrangement and the version of modutils used. Then tell us about what use case you have where this metric matters. If you say "I have a custom embedded system where every filesystem block matters", then I will say: "so go into the modules directory and arrange the directory structure the way you like it". I'll tell you what matters to me: correctness and simplicity. Keith killed a lot of swampy nasty code and I'm grateful. That's way more important to me than the "file access time" difference between /lib/modules/2.4.0/char/serial.o and /lib/modules/2.4.0/kernel/drivers/char/serial.o. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
> And what's up with the explosion of directories? The existing system had at least three problems: (1) Rules.make had a load of ugly code to translate from the source tree to the symlink farm. This code had plenty of bugs and race conditions (e.g. if two subdirectories have the same MOD_LIST_NAME and make runs in parallel). (2) The top Makefile had a butt-load of even uglier code to translate from the symlink farm to the install tree. This code needed to be coordinated with modutils releases. It also suffered from bugs, such as configuration changes leaving stale files around. (3) Module names had to be unique across the entire kernel tree, which is a silly limitation. So now, the module installation code is simple and correct and doesn't need to be updated in tandem with modutils every two weeks. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
And what's up with the explosion of directories? The existing system had at least three problems: (1) Rules.make had a load of ugly code to translate from the source tree to the symlink farm. This code had plenty of bugs and race conditions (e.g. if two subdirectories have the same MOD_LIST_NAME and make runs in parallel). (2) The top Makefile had a butt-load of even uglier code to translate from the symlink farm to the install tree. This code needed to be coordinated with modutils releases. It also suffered from bugs, such as configuration changes leaving stale files around. (3) Module names had to be unique across the entire kernel tree, which is a silly limitation. So now, the module installation code is simple and correct and doesn't need to be updated in tandem with modutils every two weeks. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
Well, there's butt-loads of ugly Makefile shit all over the place. It isn't going away. Some of it went away when Keith Owens rewrote modules-install. More of it went away between 2.2 and 2.4. Check out drivers/net/Makefile or drivers/scsi/Makefile or lots of other Makefiles, for instance. They are 1/3 the size they used to be. Even more of it's going away in 2.5. Here's my contribution to making it go away: ftp://ftp.shout.net/pub/users/mec/kbuild/dancing-makefiles-2.3.26 ftp://ftp.shout.net/pub/users/mec/kbuild/x-Dkm-9.diff Where is yours? Yes and no. You can only insmod _one_ serial.o so the name does have to be unique at the time it's loaded. True. But the Makefiles are no longer part of this problem. (BTW, the current modutils (2.3.15) won't see all the modules from a modules_install.) Oh? That would be a bug. Which modules does it fail to see? From an efficiency standpoint, one file per directory is a hideous waste of both filesystem space (one inode and one block) and system resources (file access times, dcache, et. al.) So, go benchmark "insmods per second". I want to see a %age from some controlled test where the only differences are the module arrangement and the version of modutils used. Then tell us about what use case you have where this metric matters. If you say "I have a custom embedded system where every filesystem block matters", then I will say: "so go into the modules directory and arrange the directory structure the way you like it". I'll tell you what matters to me: correctness and simplicity. Keith killed a lot of swampy nasty code and I'm grateful. That's way more important to me than the "file access time" difference between /lib/modules/2.4.0/char/serial.o and /lib/modules/2.4.0/kernel/drivers/char/serial.o. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
However, NO ONE has taken the time (I'm talking weeks of doing nothing but screwing with Makefiles) to completely rewrite the build system. I have done exactly that. And I gave you the URL. You want to read it, or you want to keep whining that "NO ONE" is doing the work I am pointing you directly to? What's the point in making processors faster if everyone just wastes the increase being "correct and simple"? I've also benchmarked my Makefiles against the stock kernel Makefiles. The "correct and simple" Makefiles run in 1/2 the time. Honestly, it's like talking to a wall here. Rick, you don't know what you're talking about, and you show too much unwillingness to learn. I'm not interested in your prejudices any more. *plonk* Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
In the .config file, the problem is that the Makefiles source .config and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300 instances of this in 2.4.0-test-7. In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S) files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH) tests. There are about 8000 instances of this in 2.4.0-test-7. Even worse, any third-party module source is likely to contain the same "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will silently break all of them. I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: modules_install?
And how much did RedHat pay you to do it? Legitimate question. Answer: zero. I wrote it long before I started working for Red Hat. Oh, I know more than you think I do. No, judging by your posts, you don't. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Yeah. Long transition, plus user education (which never works, dontcha know), plus probably a helper tool akin to checkconfig. I think it would help to have a well documented "module writers kit". (Maybe there is one and I'm not aware of it). mec I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to mec be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon. peter Am I being obtuse? What is the functional difference? Doh, I am thinking in the wrong language again! "CONFIG_BAR - 0" works when $CONFIG_BAR might expand to either "" or "1". But that's not what happens in 2.4.0 and it's not what happens under Al Viro's proposal. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus writes ... mec> (2) Make the architecture a configuration variable (!) linus> Why? The real reason is that it's the right thing to do. Part of a configuration is "what machine it's for". Here are some benefits: (a) Arjan's testing machinery would catch problems in all architectures, not just the x86. (b> The sparc / sparc64 people can manage their builds a lot easier. (c) With separate source and build trees, which I've implemented, it becomes a lot more feaasible to manage kernel builds for multiple platforms. > Hey, maybe you have a few 18GB disks lying around, but none of the > machines I use every day could afford to have another 5-6 cross- > compilation environments lying around. It's just not practical. So don't do it. You build with your favorite configuration, and I'll build with my favorite 100 configurations. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
r > (0) knowledge that CONFIG.FOO15 doesn't affect anything other than set of > source files being compiled. The Makefiles already know this. Specifically, mkdep.c analyzes which C files depend on which options. Look at some of your .depend files. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. With this stuff available, I would spend my idle cycles building random kernels and catching the syntax errors. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
We could use some more infrastructure here. (1) A 'make randomconfig' tool that generates a random configuration. (2) Make the architecture a configuration variable (!) (3) A collection of RPM's so that people can download and install all the cross tools easily. With this stuff available, I would spend my idle cycles building random kernels and catching the syntax errors. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM
Linus writes ... mec (2) Make the architecture a configuration variable (!) linus Why? The real reason is that it's the right thing to do. Part of a configuration is "what machine it's for". Here are some benefits: (a) Arjan's testing machinery would catch problems in all architectures, not just the x86. (b The sparc / sparc64 people can manage their builds a lot easier. (c) With separate source and build trees, which I've implemented, it becomes a lot more feaasible to manage kernel builds for multiple platforms. Hey, maybe you have a few 18GB disks lying around, but none of the machines I use every day could afford to have another 5-6 cross- compilation environments lying around. It's just not practical. So don't do it. You build with your favorite configuration, and I'll build with my favorite 100 configurations. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tracing in the presence of forks.
> Is there any mechanism to automatically stop a process created > by a traced parent preventing this race condition from occurring ? Yeah, use ptrace to stop on every child system call. When the child calls fork(), then change its memory at the return instruction to "jmp ." instruction. Then the grandchild will be born into slavery and you can attach to it before it runs away. Works for me. You could do the same thing without stopping on every system call by assuming that "fork" is the only function that actually calls the kernel to fork, and setting breakpoints in there and then doing the "jmp ." trick. That doesn't protect against children that are actively seeking to evade control but it ought to work on all well behaved citizens. Gosh, I feel like Big Brother now. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
I'm beginning to think that installation should copy everyting (bzImage, System.map, modules) into /lib/modules/. This split between resident and modules just causes endless hassle. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Makefile
"else if" is legal syntax, just like "else ls" or "else any other command". Your example is broken. You have two "if" statements, but only one "fi". If you look at your results, all your shells are complaining about the unmatched "if". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH]: Makefile
"else if" is legal syntax, just like "else ls" or "else any other command". Your example is broken. You have two "if" statements, but only one "fi". If you look at your results, all your shells are complaining about the unmatched "if". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
> Because it is easier to solve the problem in user space. I have to disagree with Keith here. It's more reliable to solve the problem in kernel space. /proc/config.gz is guaranteed to hold the configuration of the running kernel (if it exists at all). But /lib/modules//.config might match the running kernel, or it might not, depending on whether someone has messed with the system. And people do mess with systems, and then do call support lines. /lib/modules//.config is a big step up from the current situation and I'm grateful. But I do want /proc/config.gz in the kernel. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
