Re: mainlining min-configs...
On Wednesday 11 June 2008 14:46:55 Tim Bird wrote: > Adrian Bunk wrote: > > Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since > > April 2006. > > Well, dangit there it is! > > The patch I googled had it going into Documentation/kbuild. It > somehow escaped my attention in the README. Mine as well. (I grepped for KCONFIG_ALLCONFIG in Documentation, not in the rest of the tree. I of all people should know better...) > If I was > a little more skilled with my grep-ing I would have found it. > Sorry for the bother! The linux kernel has documentation in Documentation, in the "make htmldocs" output, in the Kconfig help entries, in README files, in the output of "make help", and several other places. (And then there's all the stuff that's not _in_ the kernel tarball...) It's easy to miss. Rob P.S: yes, README files plural. find . -name "*[Rr][Ee][Aa][Dd][Mm][Ee]*" | grep -v Documentation | wc 6969 2315 -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] Embedded Maintainer(s), [EMAIL PROTECTED] list
On Wednesday 11 June 2008 00:47:36 Greg Ungerer wrote: > Hi Rob, > > Rob Landley wrote: > > On Tuesday 10 June 2008 02:54:32 Sam Ravnborg wrote: > >>> (Maybe I _am_ the only person who still cares about > >>> building on a host without perl. If I wasn't, somebody else would have > >>> acked the patch...) > >> > >> perl is pretty standard > > > > An implementation is not the same thing as a standard. If you mean > > "there is one implementation everybody uses, ala excel and Word, and even > > the Perl guys can't reproduce it from scratch as parrot showed", then > > you're using a different definition of the word "standard" than I am. > > > > Or do you mean it comes preinstalled on most modern systems, the way > > Windows does, and who could object to that? > > > > I know from experience that it's an _amazing_ pain to try to cross > > compile the sucker... > > Ain't that the truth! > > >> and I fail to see the benefits of avoiding it. > >> For embedded development I see even less benefits as I assume > >> any sane embedded development environment are based on a > >> cross-toolchain so you do the build on a high perfomance box. > >> > >> Building everything for my arm board on the arm board would be a disater > >> for example. > > > > I build everything for my arm board natively, on an arm system running > > under qemu, calling out to the cross compiler via distcc to accelerate > > the limited parts of the process that cross compiling doesn't actually > > break. To get to that point, I cross compile just enough to get a native > > development environment, and then I avoid cross compiling from then on > > because it's an enormous source of complexity and random breakage. > > Random breakage? Cross compiling breaks stuff, yes. Most packages don't cross compile at all. Debian has somewhere north of 30,000 packages. Every project that does large scale cross compiling (buildroot, gentoo embedded, timesys making fedora cross compile, etc) tends to have about 200 packages that cross compile more or less easily, another 400 or so that can be made to cross compile with _lot_ of effort and a large enough rock, and then the project stalls at about that size. > > I did this because throwing hardware at the problem is cheaper than > > throwing engineering time at the problem, because Moore's Law is on my > > side, and > > Are you sure about that? > How well does qemu do SMP? At all? QEMU does not currently do SMP at all. There are proposals to make qemu multi-threaded and handle SMP that way, but they're at least a year away from anybody actually trying to implement them. (The big destabilization right now is the new code generator, and that's plenty for the moment. Anybody who wanted to wave money at codesourcery could probably get it implemented on a deadline for their platforms of interest, but in the absence of that it's not really a priority right now.) Distcc can take advantage of smp, but that won't help the ./configure stage and I need to do some work on distcc to teach it to understand more gcc command lines. (For one thing, distcc can't break "compile and link" commands ala "gcc hello.c" into separate "compile" and "link" stages, this it can't distribute those. This takes out pretty much the entire uClibc build, for example. But the gcc build parallelizes quite well.) > Modern x86 and friends are getting most new performance from > more cores. A cross compile today can take advantage of those > for the most part. Your emulated system probably can't. It can if you're using distcc to call out to the cross compiler, which my scripts do (./emulator-build.sh does it with the build/* stuff and ./run-with-distcc.sh does it for the shipped system-image tarballs). Some of the other build systems out there hook qemu application emulation up to the kernel's misc binary support so a ./configure that builds arm executables can run them. (Openembedded, was it? Open moko? Something like that.) But this only solves one of about a dozen major problems cross compiling is prone to. Building natively solves all of 'em, except for speed. > An order of magnitude compile time (or more) for a native build > is quite a high price to pay :-) Yup. Agreed. No argument there. However, having one or more full-time engineers devoted to debugging cross-compile issues is quite a high price to pay too. Moore's law really doesn't help that one. I'm not saying either solution is perfect, I'm just saying the "build under emulation" approach is a viable alternative that gets more attractive as time passes, both because of ongoing development on emulators and because of Moore's law on the hardware. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Wednesday 11 June 2008 14:09:56 Tim Bird wrote: > Sam Ravnborg wrote: > >>> When I get my kconfig patchset polished you will be able to do: > >>> > >>> make K=my_mini_config allnoconfig > >> > >> So you're renaming KCONFIG_ALLNOCONFIG then? > > > > Somehow yes. The K= notation I hope will see more use. Only very few > > people know the KCONFIG_ALL*CONFIG= trick. > > Indeed. I had never heard of it, but it appears to have been > around for at least 18 months. It looks like Randy Dunlap tried > to submit some documentation for this in Oct 2006, but it didn't > make it in? Nor did the documentation I posted back in November 2005: http://lwn.net/Articles/160497/ Nor its resubmission: http://lwn.net/Articles/161086/ Nor its re-resubmission: http://lkml.org/lkml/2006/7/6/404 Randy's submission was after those three... Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
Adrian Bunk wrote: > Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since > April 2006. Well, dangit there it is! The patch I googled had it going into Documentation/kbuild. It somehow escaped my attention in the README. If I was a little more skilled with my grep-ing I would have found it. Sorry for the bother! -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Wed, Jun 11, 2008 at 10:36:39PM +0300, Adrian Bunk wrote: > On Wed, Jun 11, 2008 at 12:09:56PM -0700, Tim Bird wrote: > > Sam Ravnborg wrote: > > >>> When I get my kconfig patchset polished you will be able to do: > > >>> > > >>> make K=my_mini_config allnoconfig > > >> So you're renaming KCONFIG_ALLNOCONFIG then? > > > > > > Somehow yes. The K= notation I hope will see more use. Only very few > > > people know the KCONFIG_ALL*CONFIG= trick. > > > > Indeed. I had never heard of it, but it appears to have been > > around for at least 18 months. It looks like Randy Dunlap tried > > to submit some documentation for this in Oct 2006, but it didn't > > make it in? > >... > > Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since > April 2006. The one I refer to is not. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Wed, Jun 11, 2008 at 12:09:56PM -0700, Tim Bird wrote: > Sam Ravnborg wrote: > >>> When I get my kconfig patchset polished you will be able to do: > >>> > >>> make K=my_mini_config allnoconfig > >> So you're renaming KCONFIG_ALLNOCONFIG then? > > > > Somehow yes. The K= notation I hope will see more use. Only very few > > people know the KCONFIG_ALL*CONFIG= trick. > > Indeed. I had never heard of it, but it appears to have been > around for at least 18 months. It looks like Randy Dunlap tried > to submit some documentation for this in Oct 2006, but it didn't > make it in? >... Randy's patch that documents KCONFIG_ALLCONFIG is in Linus' tree since April 2006. > -- Tim cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
On Wed, Jun 11, 2008 at 12:09:56PM -0700, Tim Bird wrote: > Sam Ravnborg wrote: > >>> When I get my kconfig patchset polished you will be able to do: > >>> > >>> make K=my_mini_config allnoconfig > >> So you're renaming KCONFIG_ALLNOCONFIG then? > > > > Somehow yes. The K= notation I hope will see more use. Only very few > > people know the KCONFIG_ALL*CONFIG= trick. > > Indeed. I had never heard of it, but it appears to have been > around for at least 18 months. It looks like Randy Dunlap tried > to submit some documentation for this in Oct 2006, but it didn't > make it in? > > Is this feature widely used? Should it be doc'ed now > or are you about to make it obsolete? I will most likely obsolete all except KCONFIG_ALLCONFIG And I'm afraid I have Randy patch somewhere. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mainlining min-configs...
Sam Ravnborg wrote: >>> When I get my kconfig patchset polished you will be able to do: >>> >>> make K=my_mini_config allnoconfig >> So you're renaming KCONFIG_ALLNOCONFIG then? > > Somehow yes. The K= notation I hope will see more use. Only very few > people know the KCONFIG_ALL*CONFIG= trick. Indeed. I had never heard of it, but it appears to have been around for at least 18 months. It looks like Randy Dunlap tried to submit some documentation for this in Oct 2006, but it didn't make it in? Is this feature widely used? Should it be doc'ed now or are you about to make it obsolete? -- Tim = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add diffconfig utility
Geert Uytterhoeven wrote:
> No checking for excess arguments?
Holger Schurig wrote:
> Would it be helpful to compare .config.old to .config if you
> don't provide any command line arguments?
Both good ideas. These are implemented in the latest version.
Note that I check for and use KBUILD_OUTPUT. (I always put
my build output outside the source directory, since
I usually build for multiple arches from a single tree.)
The program is also now better structured, IMHO.
-- Tim
Diffconfig is a simple utility for comparing two .config files.
See usage in the script for more info.
Signed-off-by: Tim Bird <[EMAIL PROTECTED]>
scripts/diffconfig | 128 +
1 file changed, 128 insertions(+)
create mode 100755 scripts/diffconfig
diff --git a/scripts/diffconfig b/scripts/diffconfig
new file mode 100755
index 000..aa6cfe1
--- /dev/null
+++ b/scripts/diffconfig
@@ -0,0 +1,128 @@
+#!/usr/bin/python
+#
+# diffconfig - a tool to compare .config files.
+#
+# originally written in 2006 by Matt Mackall
+# (at least, this was in his bloatwatch source code)
+# last worked on 2008 by Tim Bird
+#
+
+import sys, os
+
+def usage():
+print "Usage: diffconfig [-h] [-m] [ ]\n"
+print """Diffconfig is a simple utility for comparing two .config files.
+Using standard diff to compare .config files often includes extraneous and
+distracting information. This utility produces sorted output with only the
+changes in configuration values between the two files.
+
+Added and removed items are shown with a leading plus or minus, respectively.
+Changed items show the old and new values on a single line.
+
+If -m is specified, then output will be in "merge" style, which has the changed
+and new values in kernel config option format.
+
+If no config files are specified, .config and .config.old are used.
+
+Example usage:
+ $ diffconfig .config config-with-some-changes
+-EXT2_FS_XATTR n
+-EXT2_FS_XIP n
+ CRAMFS n -> y
+ EXT2_FS y -> n
+ LOG_BUF_SHIFT 14 -> 16
+ PRINTK_TIME n -> y
+"""
+sys.exit(0)
+
+# returns a dictionary of name/value pairs for config items in the file
+def readconfig(config_file):
+d = {}
+for line in config_file:
+line = line[:-1]
+if line[:7] == "CONFIG_":
+name, val = line[7:].split("=", 1)
+d[name] = val
+if line[-11:] == " is not set":
+d[line[9:-11]] = "n"
+return d
+
+def print_config(op, config, value, new_value):
+global merge_style
+
+if merge_style:
+if new_value:
+if new_value=="n":
+print "# CONFIG_%s is not set" % config
+else:
+print "CONFIG_%s=%s" % (config, new_value)
+else:
+if op=="-":
+print "-%s %s" % (config, value)
+elif op=="+":
+print "+%s %s" % (config, new_value)
+else:
+print " %s %s -> %s" % (config, value, new_value)
+
+def main():
+global merge_style
+
+# parse command line args
+if ("-h" in sys.argv or "--help" in sys.argv):
+ usage()
+
+merge_style = 0
+if "-m" in sys.argv:
+merge_style = 1
+sys.argv.remove("-m")
+
+argc = len(sys.argv)
+if not (argc==1 or argc == 3):
+print "Error: incorrect number of arguments or unrecognized option"
+usage()
+
+if argc == 1:
+# if no filenames given, assume .config and .config.old
+build_dir=""
+if os.environ.has_key("KBUILD_OUTPUT"):
+build_dir = os.environ["KBUILD_OUTPUT"]+"/"
+
+configa_filename = build_dir + ".config.old"
+configb_filename = build_dir + ".config"
+else:
+configa_filename = sys.argv[1]
+configb_filename = sys.argv[2]
+
+a = readconfig(file(configa_filename))
+b = readconfig(file(configb_filename))
+
+# print items in a but not b (accumulate, sort and print)
+old = []
+for config in a:
+if config not in b:
+old.append(config)
+old.sort()
+for config in old:
+print_config("-", config, a[config], None)
+del a[config]
+
+# print items that changed (accumulate, sort, and print)
+changed = []
+for config in a:
+if a[config] != b[config]:
+changed.append(config)
+else:
+del b[config]
+changed.sort()
+for config in changed:
+print_config("->", config, a[config], b[config])
+del b[config]
+
+# now print items in b but not in a
+# (items from b that were in a were removed above)
+new = b.keys()
+new.sort()
+for config in new:
+print_config("+", config, None, b[config])
+
+main()
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add diffconfig utility
On Tue, 10 Jun 2008, Tim Bird wrote:
> +merge_style = 0
> +if "-m" in sys.argv:
> +merge_style = 1
> +sys.argv.remove("-m")
> +
> +if "-h" in sys.argv or len(sys.argv) < 3:
^^^
No checking for excess arguments?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Technology and Software Centre Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis 293-0376800-10 GEBA-BE-BB
Re: mainlining min-configs...
On Tue, Jun 10, 2008 at 3:37 AM, Tim Bird <[EMAIL PROTECTED]> wrote: > Any chance of getting your minimal configs from Firmware Linux mainlined? > > Does anyone else think this would be valuable? If not in mainline, it > would be nice to collect them somewhere, to compare what options different > developers decide turn on or off. > -- Tim > this is very valuable. DetaolB uses this concept. Download the latest iso of DetaolB, boot it and look for /proc/miniconfig.gz. you'll see an example for 2.6.23 there. you can find old patches there: http://downloads.sourceforge.net/detaolb/detaolb_v03-linux-2.6.21.patch -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] console - Add configurable support for console charset translation
> Does the linux-tiny approach of adding a kconfig variable for > each 5kB of code actually make sense? I'm asking since an > exploding amount of kconfig variables and their > interdependencies have a not so small maintainance impact in > the long term. I don't want to answer for the general case, but I can answer for my specific case. My device has Intel Strataflash, which have 256 kB size of erase-sectors. I reserved one sector for u-boot (which is plenty) and 4 for linux --- which uses to be plenty in the 2.4.21 days. It is no longer plenty, some years ago I switched one of the targets to 2.6.15. The 4 sectors still were ok. Some months ago I switched to 2.6.24/2.6.25 and now space is VERY scarce. Just yesterday, when I trashed unionfs because of some misbehavior I couldn't fix by myself and went with aufs. Now my kernel suddenly became 14 kB too big for my device. Now, tiny-linux patches are at 2.6.23, but I could still adapt a bunch of them to 2.6.25 and with that and some changed configs my headroom is now again 26460 bytes. Unfortunately, my custom boot logo had to go :-/ -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] add diffconfig utility
Nice. Would it be helpful to compare .config.old to .config if you don't provide any command line arguments? scripts/diffconfig would then do the job. -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
