* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Sam Ravnborg @ 2008-06-10 10:50 UTC (permalink / raw)
To: Jamie Lokier
Cc: Rob Landley, Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610102018.GB25910@shareable.org>
>
> When did this policy change, so that it's now acceptable to depend on
> Perl, which is roughly equivalent as a tool dependency?
We have perl as a mandatory part of the kernel build in several places
for various architectures.
And I do not recall anyone submitting a bug that they could not build
a kernel due to the perl dependency.
But I am obviously well aware of that we use it for the time stuff.
For the headers_* targets I will shortly introduce yet another
perl dependency - but only if these targets are used - so less of an issue.
o We shall try to keep the dependencies low for the common things
o but for the more exoctic things a wides dependency is OK.
Which is also why I'm happy to apply a patch that remove
the mandatory dependency of perl we have today - if and only if
that patch meet normal patch acceptance criterias.
Rob's initial patch had some issues and neither Rob nor I have
fixed these and therefore it has not been applied.
Rob seems to put much more into this (private reply accustions etc)
for reasons unknown to me. And doing so does not help to get me interested.
So try to get the facts correct here - there is noone against removing
the mandatory perl dependency. But it is lower on my priority list
than many other things which explain why I do not do it myself.
But if someone submit a patch to do so then if the patch is OK it
will be applied.
And if we have a policy that say no-go to perl then it is new to me.
I hope one day to rewrite part of kbuild and perl seems to be the
best candidate around. But that day may never come.
Sam
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Jamie Lokier @ 2008-06-10 13:12 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Sam Ravnborg, Rob Landley, Leon Woestenberg, David Woodhouse,
linux-embedded
In-Reply-To: <20080610090924.150D9248AC@gemini.denx.de>
Wolfgang Denk wrote:
> Being unable to do this just because we now also would need a native
> Perl is indeed a PITA...
You can run the Perl bit with "ssh remote perl", and still do the rest
of the compile natively. It's not pretty, but workable.
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Will Newton @ 2008-06-10 13:25 UTC (permalink / raw)
To: Jamie Lokier
Cc: Wolfgang Denk, Sam Ravnborg, Rob Landley, Leon Woestenberg,
David Woodhouse, linux-embedded
In-Reply-To: <20080610131236.GC28565@shareable.org>
On Tue, Jun 10, 2008 at 2:12 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Wolfgang Denk wrote:
>> Being unable to do this just because we now also would need a native
>> Perl is indeed a PITA...
>
> You can run the Perl bit with "ssh remote perl", and still do the rest
> of the compile natively. It's not pretty, but workable.
I'm not convinced it matters at all. Self hosting on an embedded
architecture is, as has been mentioned, pretty pointless.
Using a kernel compile as a test isn't such a great idea. Stress tests
of that kind are not particularly useful for pinning down bugs - so
your kernel compile failed, what now? Far better to use LTP tests or
similar that are designed to be reproduceable and tunable for your
system. For example I don't think I'll ever be able to self host a
kernel build on a board with only 32Mb of on-board RAM.
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: David Woodhouse @ 2008-06-10 13:33 UTC (permalink / raw)
To: Will Newton
Cc: Jamie Lokier, Wolfgang Denk, Sam Ravnborg, Rob Landley,
Leon Woestenberg, linux-embedded
In-Reply-To: <87a5b0800806100625m5a6d20dao47b884bff663c24c@mail.gmail.com>
On Tue, 2008-06-10 at 14:25 +0100, Will Newton wrote:
> On Tue, Jun 10, 2008 at 2:12 PM, Jamie Lokier <jamie@shareable.org> wrote:
> > Wolfgang Denk wrote:
> >> Being unable to do this just because we now also would need a native
> >> Perl is indeed a PITA...
> >
> > You can run the Perl bit with "ssh remote perl", and still do the rest
> > of the compile natively. It's not pretty, but workable.
>
> I'm not convinced it matters at all. Self hosting on an embedded
> architecture is, as has been mentioned, pretty pointless.
>
> Using a kernel compile as a test isn't such a great idea. Stress tests
> of that kind are not particularly useful for pinning down bugs - so
> your kernel compile failed, what now? Far better to use LTP tests or
> similar that are designed to be reproduceable and tunable for your
> system. For example I don't think I'll ever be able to self host a
> kernel build on a board with only 32Mb of on-board RAM.
Actually, cross-building on NFS does tend to find a _lot_ of issues
which crop up with board ports; especially PCI arbitration, DMA
coherency, cache and MMU issues. LTP often doesn't catch the same
problems.
I agree that it's not so easy on a board with 32Mb of RAM, since that's
only 4,000,000 bytes -- but 32MiB ought to be _perfectly_ sufficient :)
--
dwmw2
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Wolfgang Denk @ 2008-06-10 13:47 UTC (permalink / raw)
To: Jamie Lokier
Cc: Sam Ravnborg, Rob Landley, Leon Woestenberg, David Woodhouse,
linux-embedded
In-Reply-To: <20080610131236.GC28565@shareable.org>
In message <20080610131236.GC28565@shareable.org> you wrote:
>
> You can run the Perl bit with "ssh remote perl", and still do the rest
> of the compile natively. It's not pretty, but workable.
This may or may not work. If, for example, perl is running on a
remote little endian host (like a standard x86 PC) and we depend on
native bin endian byte order, there may be trouble...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Quote from a recent meeting: "We are going to continue having these
meetings everyday until I find out why no work is getting done."
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Will Newton @ 2008-06-10 13:47 UTC (permalink / raw)
To: David Woodhouse
Cc: Jamie Lokier, Wolfgang Denk, Sam Ravnborg, Rob Landley,
Leon Woestenberg, linux-embedded
In-Reply-To: <1213104800.32207.778.camel@pmac.infradead.org>
On Tue, Jun 10, 2008 at 2:33 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2008-06-10 at 14:25 +0100, Will Newton wrote:
>> On Tue, Jun 10, 2008 at 2:12 PM, Jamie Lokier <jamie@shareable.org> wrote:
>> > Wolfgang Denk wrote:
>> >> Being unable to do this just because we now also would need a native
>> >> Perl is indeed a PITA...
>> >
>> > You can run the Perl bit with "ssh remote perl", and still do the rest
>> > of the compile natively. It's not pretty, but workable.
>>
>> I'm not convinced it matters at all. Self hosting on an embedded
>> architecture is, as has been mentioned, pretty pointless.
>>
>> Using a kernel compile as a test isn't such a great idea. Stress tests
>> of that kind are not particularly useful for pinning down bugs - so
>> your kernel compile failed, what now? Far better to use LTP tests or
>> similar that are designed to be reproduceable and tunable for your
>> system. For example I don't think I'll ever be able to self host a
>> kernel build on a board with only 32Mb of on-board RAM.
>
> Actually, cross-building on NFS does tend to find a _lot_ of issues
> which crop up with board ports; especially PCI arbitration, DMA
> coherency, cache and MMU issues. LTP often doesn't catch the same
> problems.
It may trigger a number of bugs, I don't disagree, but as a test it is
a blunt instrument. It's likely to be hard to reproduce and have an
inconsistent failure mode. If you're really serious about testing it's
not the best solution. It's like using gcc instead of memtest86 to
test your memory. Eventually it might go wrong but you won't be much
the wiser about why, or have any way to trim your testcase down so you
can run it on an in-circuit emulator or pass it to your silicon
vendor.
> I agree that it's not so easy on a board with 32Mb of RAM, since that's
> only 4,000,000 bytes -- but 32MiB ought to be _perfectly_ sufficient :)
I would be surprised if it was possible to compile Linux with gcc 4.2
with 32MiB of total system memory.
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Wolfgang Denk @ 2008-06-10 13:49 UTC (permalink / raw)
To: Will Newton
Cc: Jamie Lokier, Sam Ravnborg, Rob Landley, Leon Woestenberg,
David Woodhouse, linux-embedded
In-Reply-To: <87a5b0800806100625m5a6d20dao47b884bff663c24c@mail.gmail.com>
In message <87a5b0800806100625m5a6d20dao47b884bff663c24c@mail.gmail.com> you wrote:
>
> I'm not convinced it matters at all. Self hosting on an embedded
> architecture is, as has been mentioned, pretty pointless.
YMMV...
> system. For example I don't think I'll ever be able to self host a
> kernel build on a board with only 32Mb of on-board RAM.
It depends. We've done this on board with as little as 16 MB RAM.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Confound these ancestors.... They've stolen our best ideas!"
- Ben Jonson
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: David Woodhouse @ 2008-06-10 13:53 UTC (permalink / raw)
To: Will Newton
Cc: Jamie Lokier, Wolfgang Denk, Sam Ravnborg, Rob Landley,
Leon Woestenberg, linux-embedded
In-Reply-To: <87a5b0800806100647r178e54c0qd34cbf26f6ce24d@mail.gmail.com>
On Tue, 2008-06-10 at 14:47 +0100, Will Newton wrote:
> On Tue, Jun 10, 2008 at 2:33 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > On Tue, 2008-06-10 at 14:25 +0100, Will Newton wrote:
> >> Using a kernel compile as a test isn't such a great idea. Stress tests
> >> of that kind are not particularly useful for pinning down bugs - so
> >> your kernel compile failed, what now? Far better to use LTP tests or
> >> similar that are designed to be reproduceable and tunable for your
> >> system. For example I don't think I'll ever be able to self host a
> >> kernel build on a board with only 32Mb of on-board RAM.
> >
> > Actually, cross-building on NFS does tend to find a _lot_ of issues
> > which crop up with board ports; especially PCI arbitration, DMA
> > coherency, cache and MMU issues. LTP often doesn't catch the same
> > problems.
>
> It may trigger a number of bugs, I don't disagree, but as a test it is
> a blunt instrument.
Yes, it's a blunt instrument, but blunt instruments are often effective.
I disagree with your claim that using it as a test isn't a good idea.
I would, however, grant you that using it as your _only_ test is a bad
idea :)
--
dwmw2
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Grant Likely @ 2008-06-10 14:00 UTC (permalink / raw)
To: David Woodhouse
Cc: Will Newton, Jamie Lokier, Wolfgang Denk, Sam Ravnborg,
Rob Landley, Leon Woestenberg, linux-embedded
In-Reply-To: <1213106008.32207.784.camel@pmac.infradead.org>
On Tue, Jun 10, 2008 at 7:53 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> On Tue, 2008-06-10 at 14:47 +0100, Will Newton wrote:
>> On Tue, Jun 10, 2008 at 2:33 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>> > On Tue, 2008-06-10 at 14:25 +0100, Will Newton wrote:
>> >> Using a kernel compile as a test isn't such a great idea. Stress tests
>> >> of that kind are not particularly useful for pinning down bugs - so
>> >> your kernel compile failed, what now? Far better to use LTP tests or
>> >> similar that are designed to be reproduceable and tunable for your
>> >> system. For example I don't think I'll ever be able to self host a
>> >> kernel build on a board with only 32Mb of on-board RAM.
>> >
>> > Actually, cross-building on NFS does tend to find a _lot_ of issues
>> > which crop up with board ports; especially PCI arbitration, DMA
>> > coherency, cache and MMU issues. LTP often doesn't catch the same
>> > problems.
>>
>> It may trigger a number of bugs, I don't disagree, but as a test it is
>> a blunt instrument.
>
> Yes, it's a blunt instrument, but blunt instruments are often effective.
>
> I disagree with your claim that using it as a test isn't a good idea.
> I would, however, grant you that using it as your _only_ test is a bad
> idea :)
Just to add my voice to the chorus; I fully agree. Brute force
testing is useful. It can expose corner cases that haven't been
considered in formal test suites.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Wolfgang Denk @ 2008-06-10 14:01 UTC (permalink / raw)
To: Will Newton
Cc: David Woodhouse, Jamie Lokier, Sam Ravnborg, Rob Landley,
Leon Woestenberg, linux-embedded
In-Reply-To: <87a5b0800806100647r178e54c0qd34cbf26f6ce24d@mail.gmail.com>
In message <87a5b0800806100647r178e54c0qd34cbf26f6ce24d@mail.gmail.com> you wrote:
>
> I would be surprised if it was possible to compile Linux with gcc 4.2
> with 32MiB of total system memory.
Hint: if memory really gets tight, you can use swap space. Either to
a local drive (either through PCI or PCMCIA/PCCard or USB or FW or
...), or over the network. This just adds another level of stress
testing to areas in the kernel that are not so well covered by some
other tests.
Guess who found out that swap on MPC8xx was broken for a long, long
time, and how it was detected?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
- Terry Pratchett, _Eric_
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Jamie Lokier @ 2008-06-10 14:29 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Will Newton, David Woodhouse, Sam Ravnborg, Rob Landley,
Leon Woestenberg, linux-embedded
In-Reply-To: <20080610140139.9817F2430C@gemini.denx.de>
Wolfgang Denk wrote:
> In message <87a5b0800806100647r178e54c0qd34cbf26f6ce24d@mail.gmail.com> you wrote:
> >
> > I would be surprised if it was possible to compile Linux with gcc 4.2
> > with 32MiB of total system memory.
>
> Hint: if memory really gets tight, you can use swap space. Either to
> a local drive (either through PCI or PCMCIA/PCCard or USB or FW or
> ...), or over the network. This just adds another level of stress
> testing to areas in the kernel that are not so well covered by some
> other tests.
Great, I'm looking forward to your implementation of swap on no-MMU!
Thanks,
-- Jamie
^ permalink raw reply
* Re: [PATCH 0/1] Embedded Maintainer(s), linux-embedded@vger list
From: Tim Bird @ 2008-06-10 17:36 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Rob Landley, Leon Woestenberg, David Woodhouse, linux-embedded
In-Reply-To: <20080610075432.GB776@uranus.ravnborg.org>
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 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.
It is true that perl is pervasive and standard, in most scenarios.
However, it is not uncommon in the embedded world for people
to strive to containerize the build process for a whole distro (kernel
included) in order to reduce problems with configure scripts that
(incorrectly) probe the host environment. I know of at least 3 distros
or distro-building methods that do this. Working to reduce the
complexity of these constrained environments is a valid goal.
My own reasons for wanting to avoid using perl, however, aren't
based on its availability.
I don't want to start a language war, but in general I think adding
"knowledge of perl" to the list of things someone needs to understand
in order to understand how to build the kernel, would be a bad thing.
There's already a huge mountain to climb for someone trying to learn
enough to modify the kernel (or it's build system). Adding perl
doesn't IMHO contribute enough value to warrant this extension in
required knowledge.
Also (again IMHO), perl is harder to maintain than other alternatives,
if a full-service scripting language is really needed.
I don't care so much if perl is used in some non-essential role,
like python is used for bloat-o-meter, for example. But it would
be nice, IMHO, to minimize the external dependencies for required
kernel build infrastructure.
Having said all this, I can't object too strenuously, since I
have some code, out of tree, that uses perl as a pre-processor.
One of the reasons I haven't submitted it is that I find its
use of perl somewhat distasteful, for the reasons mentioned
above.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: mainlining min-configs...
From: Tim Bird @ 2008-06-10 18:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Rob Landley, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080610083610.GC1987@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> But if you want to discover size change with minimal configs early you
> anyway have to both:
> - constantly keep your configs in shape so that they are both minimal
> for some set of hardware support and features and
> - investigate for any size changes what caused them
> (experience has shown that putting information on a webpage doesn't
> fix problems - even for compile errors).
Amen to that last point!
>
> You need both, and ideally constantly done by the same person against
> Linus' tree, -next and -mm.
>
> Where to get your minimal configs from at the start is just a small
> thing at the beginning - don't underestimate the required manual work
> that will have to be done each week.
This is probably why I haven't signed up for this myself previously.
I'd be interested in finding out the rate at which defconfigs
bitrot in mainline. My experience is that usually a 'make oldconfig'
will produce something usable. But maybe that wouldn't be as
effective with a minconfig?
Maybe I'll collect some minconfigs, and try maintaining them
in my own tree for a few releases to see how onerous it is...
The problem is that I can only reasonably do this for boards
I have, so there'd only be a few. But maybe that'd be enough.
They would really only be meant as examples.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: mainlining min-configs...
From: Adrian Bunk @ 2008-06-10 18:30 UTC (permalink / raw)
To: Tim Bird; +Cc: Rob Landley, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <484EC576.5080302@am.sony.com>
On Tue, Jun 10, 2008 at 11:18:30AM -0700, Tim Bird wrote:
> Adrian Bunk wrote:
>...
> > You need both, and ideally constantly done by the same person against
> > Linus' tree, -next and -mm.
> >
> > Where to get your minimal configs from at the start is just a small
> > thing at the beginning - don't underestimate the required manual work
> > that will have to be done each week.
>
> This is probably why I haven't signed up for this myself previously.
> I'd be interested in finding out the rate at which defconfigs
> bitrot in mainline. My experience is that usually a 'make oldconfig'
> will produce something usable. But maybe that wouldn't be as
> effective with a minconfig?
>...
Someone has to run the 'make oldconfig' for all configs...
And no, you cannot get that completely automated.
> -- 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
^ permalink raw reply
* Re: mainlining min-configs...
From: Sam Ravnborg @ 2008-06-10 18:51 UTC (permalink / raw)
To: Adrian Bunk
Cc: Tim Bird, Rob Landley, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080610183004.GG11685@cs181133002.pp.htv.fi>
On Tue, Jun 10, 2008 at 09:30:04PM +0300, Adrian Bunk wrote:
> On Tue, Jun 10, 2008 at 11:18:30AM -0700, Tim Bird wrote:
> > Adrian Bunk wrote:
> >...
> > > You need both, and ideally constantly done by the same person against
> > > Linus' tree, -next and -mm.
> > >
> > > Where to get your minimal configs from at the start is just a small
> > > thing at the beginning - don't underestimate the required manual work
> > > that will have to be done each week.
> >
> > This is probably why I haven't signed up for this myself previously.
> > I'd be interested in finding out the rate at which defconfigs
> > bitrot in mainline. My experience is that usually a 'make oldconfig'
> > will produce something usable. But maybe that wouldn't be as
> > effective with a minconfig?
> >...
>
> Someone has to run the 'make oldconfig' for all configs...
>
> And no, you cannot get that completely automated.
When I get my kconfig patchset polished you will be able to do:
make K=my_mini_config allnoconfig
Thus selecting 'no' for all new symbols in an automated fashion.
I know that in a few cases 'no' is the wrong answer but in the
99% of the cases 'no' is perfectly valid.
Sam
^ permalink raw reply
* Re: mainlining min-configs...
From: Adrian Bunk @ 2008-06-10 19:05 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Tim Bird, Rob Landley, linux-tiny, linux-embedded, linux kernel
In-Reply-To: <20080610185123.GA15838@uranus.ravnborg.org>
On Tue, Jun 10, 2008 at 08:51:23PM +0200, Sam Ravnborg wrote:
> On Tue, Jun 10, 2008 at 09:30:04PM +0300, Adrian Bunk wrote:
> > On Tue, Jun 10, 2008 at 11:18:30AM -0700, Tim Bird wrote:
> > > Adrian Bunk wrote:
> > >...
> > > > You need both, and ideally constantly done by the same person against
> > > > Linus' tree, -next and -mm.
> > > >
> > > > Where to get your minimal configs from at the start is just a small
> > > > thing at the beginning - don't underestimate the required manual work
> > > > that will have to be done each week.
> > >
> > > This is probably why I haven't signed up for this myself previously.
> > > I'd be interested in finding out the rate at which defconfigs
> > > bitrot in mainline. My experience is that usually a 'make oldconfig'
> > > will produce something usable. But maybe that wouldn't be as
> > > effective with a minconfig?
> > >...
> >
> > Someone has to run the 'make oldconfig' for all configs...
> >
> > And no, you cannot get that completely automated.
>
> When I get my kconfig patchset polished you will be able to do:
>
> make K=my_mini_config allnoconfig
make KCONFIG_ALLCONFIG=my_mini_config allnoconfig
already does the same.
> Thus selecting 'no' for all new symbols in an automated fashion.
> I know that in a few cases 'no' is the wrong answer but in the
> 99% of the cases 'no' is perfectly valid.
The 1% contain cases like e.g. a kconfig variable you need getting
a new dependency.
> Sam
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
^ permalink raw reply
* [PATCH] add diffconfig utility
From: Tim Bird @ 2008-06-10 19:41 UTC (permalink / raw)
To: linux-embedded; +Cc: linux kernel
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.
I have found this handy for use in testing to
detect when option dependencies unexpectedly affect
other options.
To use, apply the patch and 'chmod a+x scripts/diffconfig'
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
diffconfig | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 90 insertions(+)
--- linux-2.6.24.orig/scripts/diffconfig 1969-12-31 16:00:00.000000000 -0800
+++ test-linux/scripts/diffconfig 2008-06-10 12:11:14.000000000 -0700
@@ -0,0 +1,90 @@
+#!/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)
+#
+# 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.
+#
+# Example usage:
+# $ diffconfig .config config-test-nfs-off
+# -LOCKD y
+# -LOCKD_V4 y
+# -NFS_COMMON y
+# -NFS_DIRECTIO n
+# -NFS_V3 y
+# -NFS_V3_ACL n
+# -NFS_V4 n
+# -ROOT_NFS y
+# -RPCSEC_GSS_KRB5 n
+# -RPCSEC_GSS_SPKM3 n
+# -SUNRPC y
+# -SUNRPC_BIND34 n
+# NFS_FS y -> n
+
+import sys, os
+
+if len(sys.argv) < 3:
+ print "Usage: diffconfig <config1> <config2>"
+ 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
+
+a = readconfig(file(sys.argv[1]))
+b = readconfig(file(sys.argv[2]))
+
+# 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 "-%s %s" % (config, a[config])
+ 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 " %s %s -> %s" % (config, a[config], b[config])
+ del b[config]
+
+# now print items in b but not in a
+
+# the items from b that were in a (either the same or that changed) were removed
+# the only items left were not in a
+new = b.keys()
+
+new.sort()
+
+for config in new:
+ print "+%s %s" % (config, b[config])
^ permalink raw reply
* Re: minimum config for an ARM qemu target
From: Tim Bird @ 2008-06-10 20:43 UTC (permalink / raw)
To: Michael Opdenacker; +Cc: linux-tiny, linux-embedded
In-Reply-To: <484EDFBD.2080307@free-electrons.com>
Michael Opdenacker wrote:
> Here's one such configuration:
> http://free-electrons.com/tmp/versatile_qemu_defconfig
>...
> Or would you prefer to have the exact configuration I used last year? In
> this case, the configuration is in
> http://free-electrons.com/pub/qemu/demos/arm/directfb/1.0/
Thanks - this is just what I'm interested in.
I downloaded both, and it turns out that they're very similar:
diffconfig versatile_qemu_defconfig config-qemu-arm-2.6.20
-PRINTK_TIME n
INITRAMFS_SOURCE "" -> "../rootfs"
PRINTK y -> n
+INITRAMFS_ROOT_GID 0
+INITRAMFS_ROOT_UID 0
Only PRINTK and PRINTK_TIME are different (from a size-affecting
perspective).
Thanks a bunch!
-- Tim
P.S. I remember Matt saying that the linux-tiny list is deprecated, so
I'm copying (after the fact) linux-embedded on this thread.
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] add diffconfig utility
From: Jörn Engel @ 2008-06-10 21:02 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux kernel
In-Reply-To: <484ED902.9040000@am.sony.com>
On Tue, 10 June 2008 12:41:54 -0700, Tim Bird wrote:
> Delivery-date: Tue, 10 Jun 2008 21:44:08 +0200
> From: Tim Bird <tim.bird@am.sony.com>
> To: linux-embedded <linux-embedded@vger.kernel.org>
> CC: linux kernel <linux-kernel@vger.kernel.org>
> Subject: [PATCH] add diffconfig utility
Neat. But I have one nagging question: who do you expect to merge this
patch? ;)
Jörn
--
Premature optimization is the root of all evil.
-- Donald Knuth
^ permalink raw reply
* Re: [PATCH] add diffconfig utility
From: Sam Ravnborg @ 2008-06-10 21:18 UTC (permalink / raw)
To: Jörn Engel; +Cc: Tim Bird, linux-embedded, linux kernel
In-Reply-To: <20080610210217.GA2432@logfs.org>
On Tue, Jun 10, 2008 at 11:02:18PM +0200, Jörn Engel wrote:
> On Tue, 10 June 2008 12:41:54 -0700, Tim Bird wrote:
> > Delivery-date: Tue, 10 Jun 2008 21:44:08 +0200
> > From: Tim Bird <tim.bird@am.sony.com>
> > To: linux-embedded <linux-embedded@vger.kernel.org>
> > CC: linux kernel <linux-kernel@vger.kernel.org>
> > Subject: [PATCH] add diffconfig utility
>
> Neat. But I have one nagging question: who do you expect to merge this
> patch? ;)
I will merge it if the feedabck is positive and eventual feedback
is dealt with. (And Tim reminds me to do so in a week or so).
I take most of the random scripts in scripts/ via kbuild.git.
Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] add diffconfig utility
From: Sam Ravnborg @ 2008-06-10 21:21 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux kernel
In-Reply-To: <484ED902.9040000@am.sony.com>
On Tue, Jun 10, 2008 at 12:41:54PM -0700, Tim Bird wrote:
> 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.
>
> I have found this handy for use in testing to
> detect when option dependencies unexpectedly affect
> other options.
>
> To use, apply the patch and 'chmod a+x scripts/diffconfig'
>
> Signed-off-by: Tim Bird <tim.bird@am.sony.com>
>
> diffconfig | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 90 insertions(+)
>
> --- linux-2.6.24.orig/scripts/diffconfig 1969-12-31 16:00:00.000000000 -0800
> +++ test-linux/scripts/diffconfig 2008-06-10 12:11:14.000000000 -0700
> @@ -0,0 +1,90 @@
> +#!/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)
> +#
> +# 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.
> +#
> +# Example usage:
> +# $ diffconfig .config config-test-nfs-off
> +# -LOCKD y
> +# -LOCKD_V4 y
> +# -NFS_COMMON y
> +# -NFS_DIRECTIO n
> +# -NFS_V3 y
> +# -NFS_V3_ACL n
> +# -NFS_V4 n
> +# -ROOT_NFS y
> +# -RPCSEC_GSS_KRB5 n
> +# -RPCSEC_GSS_SPKM3 n
> +# -SUNRPC y
> +# -SUNRPC_BIND34 n
> +# NFS_FS y -> n
> +
> +import sys, os
> +
> +if len(sys.argv) < 3:
> + print "Usage: diffconfig <config1> <config2>"
> + sys.exit(0)
I know this is unix style to be very short in usage - but then they
have man pages.
Could we add a bit more from the nice description above to usage?
> +
> +# 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
> +
> +a = readconfig(file(sys.argv[1]))
> +b = readconfig(file(sys.argv[2]))
> +
> +# 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 "-%s %s" % (config, a[config])
> + 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 " %s %s -> %s" % (config, a[config], b[config])
> + del b[config]
> +
> +# now print items in b but not in a
> +
> +# the items from b that were in a (either the same or that changed) were removed
> +# the only items left were not in a
> +new = b.keys()
> +
> +new.sort()
> +
> +for config in new:
> + print "+%s %s" % (config, b[config])
No feedback on the implmentation - I do not speak phython.
Sam
^ permalink raw reply
* execute bit on scripts (was Re: [PATCH] add diffconfig utility)
From: Tim Bird @ 2008-06-10 21:33 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Jörn Engel, linux-embedded, linux kernel
In-Reply-To: <20080610211841.GA23855@uranus.ravnborg.org>
Sam Ravnborg wrote:
> I will merge it if the feedabck is positive and eventual feedback
> is dealt with. (And Tim reminds me to do so in a week or so).
Thanks.
> I take most of the random scripts in scripts/ via kbuild.git.
OK - sounds like you're the right person to ask a question
that has been nagging me.
Is there a proper way to get the execute bit set in the git tree
on patches that contain scripts? I think patches
produced by git have something that sets the file permissions?
Is this something that can (or should) be hand-added to
a non-git patch? (I use quilt).
I put that blurb in the patch description about doing a
'chmod a+x', but that doesn't seem reliable.
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
* Re: [PATCH] add diffconfig utility
From: David Woodhouse @ 2008-06-10 22:07 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded, linux kernel
In-Reply-To: <484ED902.9040000@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
On Tue, 2008-06-10 at 12:41 -0700, Tim Bird wrote:
> +# 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.
It'd be really nice if it could give its output in the same form as
the .config file itself -- so it'd look something like:
# CONFIG_FOO is not set
CONFIG_BAR=y
That can be used with this kind of tool too...
--
dwmw2
[-- Attachment #2: merge.pl --]
[-- Type: application/x-perl, Size: 1400 bytes --]
^ permalink raw reply
* Re: execute bit on scripts (was Re: [PATCH] add diffconfig utility)
From: Jan Engelhardt @ 2008-06-10 22:26 UTC (permalink / raw)
To: Tim Bird; +Cc: Sam Ravnborg, Jörn Engel, linux-embedded, linux kernel
In-Reply-To: <484EF323.7000809@am.sony.com>
On Tuesday 2008-06-10 23:33, Tim Bird wrote:
>
>> I take most of the random scripts in scripts/ via kbuild.git.
>
>OK - sounds like you're the right person to ask a question
>that has been nagging me.
>
>Is there a proper way to get the execute bit set in the git tree
>on patches that contain scripts? I think patches
>produced by git have something that sets the file permissions?
If the patch was produced with git it should have a line like
new file mode 100755
^ permalink raw reply
* Re: [PATCH] add diffconfig utility
From: Tim Bird @ 2008-06-10 22:33 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-embedded, linux kernel
In-Reply-To: <1213135624.2534.99.camel@shinybook.infradead.org>
David Woodhouse wrote:
> On Tue, 2008-06-10 at 12:41 -0700, Tim Bird wrote:
>> +# 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.
>
> It'd be really nice if it could give its output in the same form as
> the .config file itself -- so it'd look something like:
>
> # CONFIG_FOO is not set
> CONFIG_BAR=y
Would an option for that style of output be OK?
The tool currently produces something similar
to a diff (but with changed lines compressed to
a single line for conciseness). It should be easy
to produce something that can be used with another
tool to transform one config into another.
It's unclear what to do with variables that are
supposed to be removed from the config (as opposed
to be set to "CONFIG_FOO is not set" Does merge.pl
handle this, or is this left to something like
'make oldconfig'?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox