[ Continuation on the "ARM MSM updates" thread ]
On Thu, 3 Jun 2010, Russell King wrote:
>
> It'd be nice if you'd copy me...
Yeah, the thread started out as a "I got really bored with lots of msm
patches", and then just expanded into what I think is wrong with the
sub-architectures.
> On the defconfig files, you may not like them - I don't like the
> proliferation of them either. What I've always wanted to see is
> one defconfig per class of machines - in other words, one mach-XXX.
I can understand that, but at the same time, I do think that the
"defconfig" file concept as it is now is just broken. To the point of
being unfixable. It's obviously just a copy of the final .config, and it's
fundamentally not really readable (and especially not writable) by humans.
And that all actually made some sense way-back-when, back when it was
originally done - back when our config files were tiny (compared to what
they are now), and when it ended up being the default input for the
config. It just doesn't make much sense any more. The Kconfig files
themselves end up having defaults for the core things, and the non-core
things are too many to list/edit sanely in that format.
So the original reason I want to remove them is that they are very
annoying, but the reasoning that then takes that annoyance and makes me
think seriously about removing them despite the inevitable pain factor is
that I really don't think we can even use the concept for any better
model.
Anything better would _have_ to be totally different. And no, I don't
think your "diffs against a base" model work either, because while it
would make them smaller, it would still make them basically unreadable and
uneditable by any human, which means that it's not something we should
check in - it's a generated file!
And I do think our kernel configurator language already should basically
have the expressive power to do it *sanely*. We already support including
other files, which is a requirement for any hierarchical model.
So I _think_ whatever "mach-xyz" file _should_ do something like
# Kconfig file for OMAP4ABCXYZ chip
.. set the particulars for this _particular_ chip,
ie select the particular drivers on this chip ..
include "chip-family-details" (ie maybe "base OMAP details")
include "architecture-family-details" (ie ARM Kconfig)
see? Not one flat file, and very much not something generated.
And I actually suspect we could do it with our current Kconfig file model.
IOW, in the arch/arm/Kconfig file, I think it should be doable to have
basically a
choice
prompt "ARM platform"
config ARM_PLATFORM_OMAP
bool PLATFORM_OMAP
config ARM_PLATFORM_MSM
bool PLATFORM_MSM
...
endchoice
if ARK_PLATFORM_OMAP
include "Kconfig.omap" # this will further have choices for OMAP versions
elif ARM_PLATFORM_...
and then the individual "Kconfig.platform" files could select certain
options, and then do a "include Kconfig.cpu" which would actually be the
_current_ top-level arch/arm/Kconfig.
Or something. See? Making it hierarchical (so that each individual
Kconfig.xyz file only handles a certain level of detail, and it doesn't
grow unboundedly) and making it fundamentally human readable/writable
would be a really good thing.
NOTE NOTE NOTE! I'm not at all saying it has to be done like the above
with the current Kconfig language. The above is more of a "this is how we
_could_ do it, and it would be a big conceptual improvement".
And I don't think we can get there from here unless I at some point say "I
just removed the xyz_defconfig files", at which point people will curse me
and stumble about until they actually come up with something better.
Of course, if the ARM people do something proactive like the above
_before_ I remove the defconfig files, I won't complain.
Linus
* Linus Torvalds <[email protected]> [100603 17:48]:
>
> So I _think_ whatever "mach-xyz" file _should_ do something like
>
> # Kconfig file for OMAP4ABCXYZ chip
>
> .. set the particulars for this _particular_ chip,
> ie select the particular drivers on this chip ..
>
> include "chip-family-details" (ie maybe "base OMAP details")
>
> include "architecture-family-details" (ie ARM Kconfig)
>
> see? Not one flat file, and very much not something generated.
>
> And I actually suspect we could do it with our current Kconfig file model.
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have
> basically a
>
> choice
> prompt "ARM platform"
>
> config ARM_PLATFORM_OMAP
> bool PLATFORM_OMAP
>
> config ARM_PLATFORM_MSM
> bool PLATFORM_MSM
> ...
> endchoice
>
> if ARK_PLATFORM_OMAP
> include "Kconfig.omap" # this will further have choices for OMAP versions
> elif ARM_PLATFORM_...
>
> and then the individual "Kconfig.platform" files could select certain
> options, and then do a "include Kconfig.cpu" which would actually be the
> _current_ top-level arch/arm/Kconfig.
Some of this work has been already done like I responded in the other
thread. So we could use the current omap3_defconfig for omap2, 3 & 4
with some more work. Then do the same thing for omap1. That would cut
it down by total of 38 defconfigs.
Compiling in multiple ARM platforms is trickier, we would have to get
rid of the duplicate defines like NR_IRQS, then have some common clock
framework etc. Then figure out some way to get rid of Makefile.boot.
Russell probably has some other things in mind that would have to be
changed to make this happen.
> And I don't think we can get there from here unless I at some point say "I
> just removed the xyz_defconfig files", at which point people will curse me
> and stumble about until they actually come up with something better.
>
> Of course, if the ARM people do something proactive like the above
> _before_ I remove the defconfig files, I won't complain.
Whenever you feel like it, please just go ahead and do:
$ egrep "CONFIG_ARCH_OMAP[2|3|4]=y" arch/arm/configs/* | grep -v omap3_defconfig | cut -d: -f1 | xargs rm
That way maybe you can wait a bit longer for the other defconfigs
and as an extra bonus I won't get flamed for removing these omap
defconfigs ;)
Tony
On Thu, 2010-06-03 at 07:48 -0700, Linus Torvalds wrote:
> [ Continuation on the "ARM MSM updates" thread ]
>
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > It'd be nice if you'd copy me...
>
> Yeah, the thread started out as a "I got really bored with lots of msm
> patches", and then just expanded into what I think is wrong with the
> sub-architectures.
>
> > On the defconfig files, you may not like them - I don't like the
> > proliferation of them either. What I've always wanted to see is
> > one defconfig per class of machines - in other words, one mach-XXX.
>
> I can understand that, but at the same time, I do think that the
> "defconfig" file concept as it is now is just broken. To the point of
> being unfixable. It's obviously just a copy of the final .config, and it's
> fundamentally not really readable (and especially not writable) by humans.
>
> And that all actually made some sense way-back-when, back when it was
> originally done - back when our config files were tiny (compared to what
> they are now), and when it ended up being the default input for the
> config. It just doesn't make much sense any more. The Kconfig files
> themselves end up having defaults for the core things, and the non-core
> things are too many to list/edit sanely in that format.
>
> So the original reason I want to remove them is that they are very
> annoying, but the reasoning that then takes that annoyance and makes me
> think seriously about removing them despite the inevitable pain factor is
> that I really don't think we can even use the concept for any better
> model.
>
> Anything better would _have_ to be totally different. And no, I don't
> think your "diffs against a base" model work either, because while it
> would make them smaller, it would still make them basically unreadable and
> uneditable by any human, which means that it's not something we should
> check in - it's a generated file!
Have you noticed this ..
http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130
I'm not sure of the goals, but it sounds like it might be relevant.
Daniel
On Thu, Jun 03, 2010 at 07:48:18AM -0700, Linus Torvalds wrote:
> So I _think_ whatever "mach-xyz" file _should_ do something like
>
> # Kconfig file for OMAP4ABCXYZ chip
>
> .. set the particulars for this _particular_ chip,
> ie select the particular drivers on this chip ..
>
> include "chip-family-details" (ie maybe "base OMAP details")
>
> include "architecture-family-details" (ie ARM Kconfig)
>
> see? Not one flat file, and very much not something generated.
Umm...
> And I actually suspect we could do it with our current Kconfig file model.
> IOW, in the arch/arm/Kconfig file, I think it should be doable to have
> basically a
>
> choice
> prompt "ARM platform"
>
> config ARM_PLATFORM_OMAP
> bool PLATFORM_OMAP
>
> config ARM_PLATFORM_MSM
> bool PLATFORM_MSM
> ...
> endchoice
Umm. I don't think you've actually looked at the Kconfig files if you're
writing this, because that's precisely what we already do.
arch/arm/Kconfig has a big choice statement in it to select the machine
class, and then it sources the individual arch/arm/*/Kconfig files,
which are themselves wrapped in a
if FOO
foo's options
endif
It's not one huge big "let's source everything and hope people ignore
options which don't apply to their platform" that you seem to be implying
we are doing.
The big problem with doing away with the defconfig files is more to do
with what happens _outside_ of arch/arm.
At one time, I was phasing IDE out, and didn't want to see the "IDE"
configuration options on platforms which either never had IDE support
or had had IDE support removed - unfortunately I was overruled by the
IDE/ATA developers and the conditionals we had went away.
That's just one instance, but consider when you're presented with
thousands of driver and filesystem configuration options as is the
case with modern kernels. How do you find the few options you need
to get to a point that the kernel you've built is actually useful?
Anyway, I thought we were discussing _defconfig_ files, not Kconfig
files...
What we _could_ to is introduce a:
config STD_CONFIG
bool "Enable me to generate a standard configuration for your platform"
and then have platforms conditionally select everything that's
appropriate for their use. That provides a way to avoid the ages old
issue of select forcing options on, but the user still being presented
with the option and being told the only possible value for it is 'y'.
And yes, it _is_ necessary - because if you want to turn off something
on the platform - eg, you're not using MMC and MMC fails to build -
you can still end up with a working configuration at the end of the
day.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> Compiling in multiple ARM platforms is trickier, we would have to get
> rid of the duplicate defines like NR_IRQS, then have some common clock
> framework etc. Then figure out some way to get rid of Makefile.boot.
> Russell probably has some other things in mind that would have to be
> changed to make this happen.
- Find someway to handle the wide variety of interrupt controllers.
- Be able to handle any multitude of V:P translations, including non-linear
alongside linear transations.
- Different PAGE_OFFSETs
- Different kernel VM layouts allowing for a variety of different ioremap
region sizes
and so the list goes on...
> That way maybe you can wait a bit longer for the other defconfigs
> and as an extra bonus I won't get flamed for removing these omap
> defconfigs ;)
Note that Linus is talking about removing all but one or two ARM
defconfigs - which means your omap3_defconfig will probably be
eventually culled.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, 2010-06-03 at 19:10 +0100, Russell King wrote:
> config STD_CONFIG
> bool "Enable me to generate a standard configuration for your platform"
>
> and then have platforms conditionally select everything that's
> appropriate for their use. That provides a way to avoid the ages old
> issue of select forcing options on, but the user still being presented
> with the option and being told the only possible value for it is 'y'.
>
> And yes, it _is_ necessary - because if you want to turn off something
> on the platform - eg, you're not using MMC and MMC fails to build -
> you can still end up with a working configuration at the end of the
> day.
Check out the SAT solver link I quoted in the prior email.. That sounds
like a really interesting solution. The defconfigs would ultimately hold
just what's unique to a given board, then the solver would figure out
what to else to enable just from those unique properties.
So we would still have defconfigs , but they would not have loads of
duplication like they do now.
I don't see how we can do without defconfigs altogether tho. I mean , if
you want to run a Beagle board or a Nexus one we can't just give the
users a slim ARM config and let them troll through 1000's of drivers
trying to find just those ones that work on their given board.
Daniel
On Thu, 3 Jun 2010, Russell King wrote:
>
> Umm. I don't think you've actually looked at the Kconfig files if you're
> writing this, because that's precisely what we already do.
.. but if you do this _right_, then the defconfig files would be
unnecessary.
That's my point. If you are right, then I can remove the defconfig files
entirely. Are you ready for that?
And if you aren't ready for that, then what was the point of your email?
Linus
On Thu, 3 Jun 2010, Daniel Walker wrote:
>
> I don't see how we can do without defconfigs altogether tho. I mean , if
> you want to run a Beagle board or a Nexus one we can't just give the
> users a slim ARM config and let them troll through 1000's of drivers
> trying to find just those ones that work on their given board.
Well, you also don't need the full defconfig's with the kernel.
Right now they are just noise. They actually _hide_ things, because
diffstat (and dirstat) information becomes pointless, and the diffs become
totally unreadable by any human (trust me - when the choice is between
"search for next relevant diff" or "blast it, I can't be bothered with
walking through this crap", quite often the choice is the latter).
So they are an actual burden on real development.
Linus
On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 3 Jun 2010, Daniel Walker wrote:
> >
> > I don't see how we can do without defconfigs altogether tho. I mean , if
> > you want to run a Beagle board or a Nexus one we can't just give the
> > users a slim ARM config and let them troll through 1000's of drivers
> > trying to find just those ones that work on their given board.
>
> Well, you also don't need the full defconfig's with the kernel.
>
> Right now they are just noise. They actually _hide_ things, because
> diffstat (and dirstat) information becomes pointless, and the diffs become
> totally unreadable by any human (trust me - when the choice is between
> "search for next relevant diff" or "blast it, I can't be bothered with
> walking through this crap", quite often the choice is the latter).
>
> So they are an actual burden on real development.
BTW, can't we switch to processing them with cpp? That'd cut down on the
churn big way, AFAICS, not to mention reducing the odds of missing some
of them on such changes, etc.
On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote:
> I don't see how we can do without defconfigs altogether tho. I mean , if
> you want to run a Beagle board or a Nexus one we can't just give the
> users a slim ARM config and let them troll through 1000's of drivers
> trying to find just those ones that work on their given board.
Well, Linus does have a point - I can't start a new with Kconfig and
generate a working defconfig first time mainly because of the
thounds of options there.
What I can do is get the ARM side of the configuration right, since
for the majority of cases the only thing that needs doing is selecting
the platform class and the board itself.
The problem comes with driver configuration, where you have to go
through lots of menus to find all the drivers for the platform/SoC.
That's the tedious bit, and more often than not it takes several
attempts to get everything that's necessary.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, Jun 03, 2010 at 11:18:05AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > Umm. I don't think you've actually looked at the Kconfig files if you're
> > writing this, because that's precisely what we already do.
>
> .. but if you do this _right_, then the defconfig files would be
> unnecessary.
>
> That's my point. If you are right, then I can remove the defconfig files
> entirely. Are you ready for that?
Absolutely no way are we ready for that.
> And if you aren't ready for that, then what was the point of your email?
Linus, don't make this personal.
The problem is NOT "what options which are found under the arch/arm tree
do I need".
The problem is "what options throughout the rest of the kernel do I need
to result in a usable kernel".
No amount of reorganising the Kconfig files into a heirarchial manner
(which they already are) helps. Not one bit. Because they already are.
That's not where the problem is.
For instance, if I have platform A, I know it has an RTC. How do I know
which of the 37 RTC drivers the kernel configuration presents me with to
select? Am I really expected to open up the platform and read the
device numbers off all the chips (some of which being surface mount are
abbreviated) and work out that it's a TWL4030 RTC that I should be using?
That's just one instance - and there's probably many more just like that.
Just look at "multifunction drivers" for another case in point. How the
hell do I know what multifunction driver is appropriate for a platform?
Ditto "Power supply support".
The list goes endlessly on. All those things I've mentioned are all
_outside_ of arch/arm. That's where the _real_ problem is. Solve that
problem so that it's easier for people to configure the kernel, and then
we don't need the multitude defconfig files.
That's the problem which the defconfigs are solving today.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, 3 Jun 2010, Russell King wrote:
>
> The problem comes with driver configuration, where you have to go
> through lots of menus to find all the drivers for the platform/SoC.
> That's the tedious bit, and more often than not it takes several
> attempts to get everything that's necessary.
It's often tedious for other cases too ("I just want to enable a
particular driver, what do I need to do so?"), and I do agree with Daniel
that the SAT solver approach sounds interesting as a way to solve some of
the complexities.
At the same time, "SAT solver" does scream "over-engineering failure" to
me. We've had horribly bad experiences with over-engineering in that space
before. Yes, I know about MiniSAT and that these things can be done
without necessarily huge amounts of complex code, but these things tend to
grow to huge monsters.
Who knows.
Linus
On Thu, 3 Jun 2010, Russell King wrote:
>
> No amount of reorganising the Kconfig files into a heirarchial manner
> (which they already are) helps. Not one bit. Because they already are.
> That's not where the problem is.
I don't think you read the whole thread.
Earlier on, I explained exactly what I wanted: just add some "select"
statements to pickt he things you need per the particular target
configuration. You seem to have missed that part.
In other words, you _can_ encode the information that is in the
xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
it in a human-readable manner. And the hierarchical thing is absolutely
required for that - otherwise you'd end up with just another form of the
current xyz_defconfig.
See?
In other words, you should be able to basically use "make allnoconfig"
together with a Kconfig.xyz file input to select _exactly_ the pieces you
need, and nothing else.
Linus
On Thu, Jun 03, 2010 at 11:56:53AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > No amount of reorganising the Kconfig files into a heirarchial manner
> > (which they already are) helps. Not one bit. Because they already are.
> > That's not where the problem is.
>
> I don't think you read the whole thread.
>
> Earlier on, I explained exactly what I wanted: just add some "select"
> statements to pickt he things you need per the particular target
> configuration. You seem to have missed that part.
Isn't that _also_ what I suggested with one modification - which
was based on your suggestion with a _bit_ _more_ _thought_? Oddly
that suggestion which you appear to have completely ignored - but
clearly you did get the mail because you quoted a few lines from it
in one of your subsequent replies - was based on your very idea.
The one which you said "what was the point of your mail".
Maybe the point is to discuss issues. You know, it's exceedingly
difficult to discuss things if the other side doesn't read messages
they're sent. Ergo, I don't think there's any point discussing this
any further; you've crystal clearly already stopped listening.
Maybe you should go back to that one which you gave such a flippant
reply to and re-read it, and actually productively comment on my
additional suggestion to yours?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
> On Thu, 3 Jun 2010, Daniel Walker wrote:
> > I don't see how we can do without defconfigs altogether tho. I mean , if
> > you want to run a Beagle board or a Nexus one we can't just give the
> > users a slim ARM config and let them troll through 1000's of drivers
> > trying to find just those ones that work on their given board.
>
> Well, you also don't need the full defconfig's with the kernel.
>
That's true. We already have things like KCONFIG_ALLCONFIG for these
purposes, and that's primarily what I use for buildig bootable
randconfigs for specific board/CPU combinations on SH.
On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote:
>
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > No amount of reorganising the Kconfig files into a heirarchial manner
> > (which they already are) helps. Not one bit. Because they already are.
> > That's not where the problem is.
>
> I don't think you read the whole thread.
>
> Earlier on, I explained exactly what I wanted: just add some "select"
> statements to pickt he things you need per the particular target
> configuration. You seem to have missed that part.
>
> In other words, you _can_ encode the information that is in the
> xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
> it in a human-readable manner. And the hierarchical thing is absolutely
> required for that - otherwise you'd end up with just another form of the
> current xyz_defconfig.
>
> See?
>
> In other words, you should be able to basically use "make allnoconfig"
> together with a Kconfig.xyz file input to select _exactly_ the pieces you
> need, and nothing else.
If you did this for drivers, what about disabling a driver? If we used
"select" wouldn't that force all the drivers on without allowing it to
be unselected?
Daniel
On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote:
> On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote:
> >
> > On Thu, 3 Jun 2010, Russell King wrote:
> > >
> > > No amount of reorganising the Kconfig files into a heirarchial manner
> > > (which they already are) helps. Not one bit. Because they already are.
> > > That's not where the problem is.
> >
> > I don't think you read the whole thread.
> >
> > Earlier on, I explained exactly what I wanted: just add some "select"
> > statements to pickt he things you need per the particular target
> > configuration. You seem to have missed that part.
> >
> > In other words, you _can_ encode the information that is in the
> > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
> > it in a human-readable manner. And the hierarchical thing is absolutely
> > required for that - otherwise you'd end up with just another form of the
> > current xyz_defconfig.
> >
> > See?
> >
> > In other words, you should be able to basically use "make allnoconfig"
> > together with a Kconfig.xyz file input to select _exactly_ the pieces you
> > need, and nothing else.
>
> If you did this for drivers, what about disabling a driver? If we used
> "select" wouldn't that force all the drivers on without allowing it to
> be unselected?
I already covered that in my (ignored) email where I brought up a
"STD_CONFIG" config symbol, which could be disabled to turn off all
these additional "select"s.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote:
> On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote:
> > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote:
> > >
> > > On Thu, 3 Jun 2010, Russell King wrote:
> > > >
> > > > No amount of reorganising the Kconfig files into a heirarchial manner
> > > > (which they already are) helps. Not one bit. Because they already are.
> > > > That's not where the problem is.
> > >
> > > I don't think you read the whole thread.
> > >
> > > Earlier on, I explained exactly what I wanted: just add some "select"
> > > statements to pickt he things you need per the particular target
> > > configuration. You seem to have missed that part.
> > >
> > > In other words, you _can_ encode the information that is in the
> > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
> > > it in a human-readable manner. And the hierarchical thing is absolutely
> > > required for that - otherwise you'd end up with just another form of the
> > > current xyz_defconfig.
> > >
> > > See?
> > >
> > > In other words, you should be able to basically use "make allnoconfig"
> > > together with a Kconfig.xyz file input to select _exactly_ the pieces you
> > > need, and nothing else.
> >
> > If you did this for drivers, what about disabling a driver? If we used
> > "select" wouldn't that force all the drivers on without allowing it to
> > be unselected?
>
> I already covered that in my (ignored) email where I brought up a
> "STD_CONFIG" config symbol, which could be disabled to turn off all
> these additional "select"s.
I didn't ignore it, I guess I just didn't fully understand it ..
So your saying it would drop all the selects, but keep the selected
options in tact? Or it would just turn off all the selected options?
Daniel
On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote:
> On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote:
> > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote:
> > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote:
> > > >
> > > > On Thu, 3 Jun 2010, Russell King wrote:
> > > > >
> > > > > No amount of reorganising the Kconfig files into a heirarchial manner
> > > > > (which they already are) helps. Not one bit. Because they already are.
> > > > > That's not where the problem is.
> > > >
> > > > I don't think you read the whole thread.
> > > >
> > > > Earlier on, I explained exactly what I wanted: just add some "select"
> > > > statements to pickt he things you need per the particular target
> > > > configuration. You seem to have missed that part.
> > > >
> > > > In other words, you _can_ encode the information that is in the
> > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
> > > > it in a human-readable manner. And the hierarchical thing is absolutely
> > > > required for that - otherwise you'd end up with just another form of the
> > > > current xyz_defconfig.
> > > >
> > > > See?
> > > >
> > > > In other words, you should be able to basically use "make allnoconfig"
> > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you
> > > > need, and nothing else.
> > >
> > > If you did this for drivers, what about disabling a driver? If we used
> > > "select" wouldn't that force all the drivers on without allowing it to
> > > be unselected?
> >
> > I already covered that in my (ignored) email where I brought up a
> > "STD_CONFIG" config symbol, which could be disabled to turn off all
> > these additional "select"s.
>
> I didn't ignore it, I guess I just didn't fully understand it ..
>
> So your saying it would drop all the selects, but keep the selected
> options in tact? Or it would just turn off all the selected options?
config MACH_HALIBUT
bool "Halibut Board (QCT SURF7201A)"
select I2C if STD_CONFIG
select I2C_WHATEVER if STD_CONFIG
...
That means if you enable STD_CONFIG, you'll get everything that's required
selected. If you then disable STD_CONFIG, I believe Kconfig leaves
everything that was selected as still being selected.
So, what you _could_ do is start off with a blank configuration, then
configure a kernel with STD_CONFIG enabled and you end up with everything
that's required. If you then want to disable something that's selected,
turn off STD_CONFIG first, and you'll be able to turn off individual
options.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote:
> On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote:
> > On Thu, 2010-06-03 at 20:45 +0100, Russell King wrote:
> > > On Thu, Jun 03, 2010 at 12:35:42PM -0700, Daniel Walker wrote:
> > > > On Thu, 2010-06-03 at 11:56 -0700, Linus Torvalds wrote:
> > > > >
> > > > > On Thu, 3 Jun 2010, Russell King wrote:
> > > > > >
> > > > > > No amount of reorganising the Kconfig files into a heirarchial manner
> > > > > > (which they already are) helps. Not one bit. Because they already are.
> > > > > > That's not where the problem is.
> > > > >
> > > > > I don't think you read the whole thread.
> > > > >
> > > > > Earlier on, I explained exactly what I wanted: just add some "select"
> > > > > statements to pickt he things you need per the particular target
> > > > > configuration. You seem to have missed that part.
> > > > >
> > > > > In other words, you _can_ encode the information that is in the
> > > > > xyz_defconfig files by doing it in Kconfig.xyz files instead. But you do
> > > > > it in a human-readable manner. And the hierarchical thing is absolutely
> > > > > required for that - otherwise you'd end up with just another form of the
> > > > > current xyz_defconfig.
> > > > >
> > > > > See?
> > > > >
> > > > > In other words, you should be able to basically use "make allnoconfig"
> > > > > together with a Kconfig.xyz file input to select _exactly_ the pieces you
> > > > > need, and nothing else.
> > > >
> > > > If you did this for drivers, what about disabling a driver? If we used
> > > > "select" wouldn't that force all the drivers on without allowing it to
> > > > be unselected?
> > >
> > > I already covered that in my (ignored) email where I brought up a
> > > "STD_CONFIG" config symbol, which could be disabled to turn off all
> > > these additional "select"s.
> >
> > I didn't ignore it, I guess I just didn't fully understand it ..
> >
> > So your saying it would drop all the selects, but keep the selected
> > options in tact? Or it would just turn off all the selected options?
>
> config MACH_HALIBUT
> bool "Halibut Board (QCT SURF7201A)"
> select I2C if STD_CONFIG
> select I2C_WHATEVER if STD_CONFIG
> ...
>
> That means if you enable STD_CONFIG, you'll get everything that's required
> selected. If you then disable STD_CONFIG, I believe Kconfig leaves
> everything that was selected as still being selected.
I just did a little test, and it doesn't. Kconfig would un-select all
the drivers, at least from my test.
> So, what you _could_ do is start off with a blank configuration, then
> configure a kernel with STD_CONFIG enabled and you end up with everything
> that's required. If you then want to disable something that's selected,
> turn off STD_CONFIG first, and you'll be able to turn off individual
> options.
If my test was correct we would need a new "select" variant that would
leave the options turned on in order to get something equal to the
current defconfigs.
Daniel
On Thu, 3 Jun 2010, Daniel Walker wrote:
>
> If you did this for drivers, what about disabling a driver? If we used
> "select" wouldn't that force all the drivers on without allowing it to
> be unselected?
Isn't that the point? If you have a specific platform, you don't want to
pick them, you want to get the particular config file for it as a starting
point. That's the _only_ reason to have those insane 177 defconfig files -
because you want a _particular_ one.
Once you have a particular one, you can always edit it with the regular
configuration tools - including making tweaks by hand - as much as you
want.
So the only point of the thing would always be to get a result config
file, one that you can then edit to your hearts content. And get it from a
human-readable and writable description file, so that it would make sense
to check it in to the kernel repository.
Because right now, the current defconfig files DO NOT MAKE SENSE in the
kernel repository. They are useless crud, and they hurt.
So what I do _not_ want is the current crazy "give people these totally
unreadable and unwritable raw config files". I want that extra step in
between: something that allows you to _generate_ those idiotic files, but
generate them from a reasonable human-editable template.
And a Kconfig.xyz file _could_ be such a template.
But anyway, I'm not actually all that excited about playing games with
Kconfig files either. And I simply don't care. To me, a "git rm
*defconfig" is perfectly acceptable. If you want to keep the current
defconfig files, you can keep them on some random ARM site ("Here's a
defconfig file for Nexus One").
So I'm actually perfectly fine with "no defconfig files at all, not even a
template that can generate them". You can get the files from somewhere
else where they don't hurt the kernel.
Linus
On Thu, 3 Jun 2010, Russell King wrote:
>
> I already covered that in my (ignored) email where I brought up a
> "STD_CONFIG" config symbol, which could be disabled to turn off all
> these additional "select"s.
I apparently haven't explained myself enough, because what you keep on
harping on is not something I consider acceptable.
STD_CONFIG is pointless. It's pointless because the solution to what
you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz
file at all.
So when I suggest special Kconfig files, they are meant to just generate
the templates - ie they'd _generate_ what is currently the defconfig
files. You wouldn't _have_ to use them at all.
If you _had_ to use them, you'd lose the flexibility of Kconfig and asking
questions.
Linus
On Thu, Jun 03, 2010 at 01:06:48PM -0700, Daniel Walker wrote:
> On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote:
> > config MACH_HALIBUT
> > bool "Halibut Board (QCT SURF7201A)"
> > select I2C if STD_CONFIG
> > select I2C_WHATEVER if STD_CONFIG
> > ...
> >
> > That means if you enable STD_CONFIG, you'll get everything that's required
> > selected. If you then disable STD_CONFIG, I believe Kconfig leaves
> > everything that was selected as still being selected.
>
> I just did a little test, and it doesn't. Kconfig would un-select all
> the drivers, at least from my test.
That's because it knows what the original state of the symbol is.
Yes, that's a little undesirable for our behaviour - but it can be
worked around - by saving and restarting Kconfig.
Try this:
config STD_CONFIG
bool "Standard config"
default y
config DRIVER_A
tristate "Driver A"
config ARM
def_bool y
select DRIVER_A if STD_CONFIG
and in a new directory /path/to/kernel/scripts/kconfig/mconf test.conf
If you turn off STD_CONFIG immediately, it'll turn off DRIVER_A.
However, save out the config, and re-run mconf test.conf. You'll then
find that DRIVER_A remains set even when STD_CONFIG is turned off.
So, Kconfig does have the behaviour we desire but it's not directly
accessible.
Is it worth persuing? Will Linus accept this STD_CONFIG idea or did
his lack of reply to it indicate that he's not something he's willing
to entertain?
In any case, this is my last mail on the subject. I won't be replying
to mail for at least the next four days.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Thu, 3 Jun 2010, Russell King wrote:
> On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote:
> > So your saying it would drop all the selects, but keep the selected
> > options in tact? Or it would just turn off all the selected options?
>
> config MACH_HALIBUT
> bool "Halibut Board (QCT SURF7201A)"
> select I2C if STD_CONFIG
> select I2C_WHATEVER if STD_CONFIG
> ...
>
> That means if you enable STD_CONFIG, you'll get everything that's required
> selected. If you then disable STD_CONFIG, I believe Kconfig leaves
> everything that was selected as still being selected.
>
> So, what you _could_ do is start off with a blank configuration, then
> configure a kernel with STD_CONFIG enabled and you end up with everything
> that's required. If you then want to disable something that's selected,
> turn off STD_CONFIG first, and you'll be able to turn off individual
> options.
I think this certainly makes sense, at least as a proof of concept. If
we end up with lots of
select XYZ if STD_CONFIG
then at that point it might be a good idea to introduce some variations
in the Kconfig language directly. Something like a multi-priority
select statement that would either:
- provide the minimum amount of choice to the user and forcefully
"select" a default set of options expected to enable all features of
the target hardware, or
- let the user see the "preselected" options with a chance to turn it
off, but provide a y by default right away, or
- ignore those "preselect" statement entirely, as some expert mode.
Of course the 2nd and 3rd options wouldn't necessarily mean an optimal
or even working kernel configuration would be produced.
Nicolas
On Thu, 3 Jun 2010, Linus Torvalds wrote:
>
>
> On Thu, 3 Jun 2010, Russell King wrote:
> >
> > I already covered that in my (ignored) email where I brought up a
> > "STD_CONFIG" config symbol, which could be disabled to turn off all
> > these additional "select"s.
>
> I apparently haven't explained myself enough, because what you keep on
> harping on is not something I consider acceptable.
>
> STD_CONFIG is pointless. It's pointless because the solution to what
> you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz
> file at all.
Linus, I think somehow you and Russell are talking past each other.
I must admit I don't exactly understand what your suggestion is all
about. But I however think that Russell's suggestion makes tons of
sense. Care to elaborate on what you dislike about it?
What is this Kconfig.xyz you're talking about? How different is it
from, say, arch/arm/mach-pxa/Kconfig? If you look into that file,
you'll find a bunch of select's which are fundamentally needed for the
given targets to boot. This file could be augmented with more
conditional select's
? la STD_CONFIG as Russell is advocating to actually provide defaults
for the drivers that those targets should have by default.
Nicolas
> So when I suggest special Kconfig files, they are meant to just generate
> the templates - ie they'd _generate_ what is currently the defconfig
> files. You wouldn't _have_ to use them at all.
Sure. a standard "make config" would still produce that .defconfig as
usual. Only that you'd have to turn STD_CONFIG off to be offered the
choice of enabling/disabling those drivers which are enabled by default
otherwise, just like the "make foo_defconfig" is doing now.
Nicolas
On Thu, 3 Jun 2010, Linus Torvalds wrote:
>
> I apparently haven't explained myself enough, because what you keep on
> harping on is not something I consider acceptable.
>
> STD_CONFIG is pointless. It's pointless because the solution to what
> you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz
> file at all.
To make this _really_ concrete, let me actually give you an example (but
broken and pointless) example Kconfig file, in order to _avoid_ having a
def_config file.
I do it by generating it. Let's say that I want a x86 configuration that
has USB enabled. I can basically _ask_ the Kconfig machinery to generate
that with something like this:
- create a "Mykconfig" file:
config MYCONFIG
bool
default y
select USB
source arch/x86/Kconfig
and then I just do
KBUILD_KCONFIG=Mykconfig make allnoconfig
and look what appears in the .config file. In fact, do this:
make allnoconfig
cp .config no-config
KBUILD_KCONFIG=Mykconfig make allnoconfig
cp .config my-config
diff -u no-config my-config
to see the point of it all.
Now, the above is a _trivial_ one. And it's actually broken, because I
should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT).
But with this approach you could basically generate the defconfig files.
And exactly because Kconfig files are already hierarchical, you can do
things like
- Kconfig.omap3_evm:
# Set the OMAP3 EVM-specific parts
config OMAP3EVM
bool
default y
select OMAP3_EVM_TIMERS # whatever
...
# this sets the thngs all OMAP3 cases want
source Kconfig.omap3
- Kconfig.omap3
# Set the OMAP3 specific parts
config OMAP3
bool
default y
select USB_SUPPORT
select USB
...
source Kconfig.arm
and now you'd be able to basically generate a OMAP3EVM .config file by
just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
only have to select the parts that are specific for the EVM platform,
because the generic OMAP3 support would be picked by the Kconfig.omap3
file, which in turn would not have to worry about the generic ARM parts
etc.
See?
Linus
* Linus Torvalds <[email protected]> [100603 23:30]:
>
> and now you'd be able to basically generate a OMAP3EVM .config file by
> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
> only have to select the parts that are specific for the EVM platform,
> because the generic OMAP3 support would be picked by the Kconfig.omap3
> file, which in turn would not have to worry about the generic ARM parts
> etc.
>
> See?
Sounds like a good improvment to me.
Tony
* Russell King <[email protected]> [100603 21:07]:
> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > Compiling in multiple ARM platforms is trickier, we would have to get
> > rid of the duplicate defines like NR_IRQS, then have some common clock
> > framework etc. Then figure out some way to get rid of Makefile.boot.
> > Russell probably has some other things in mind that would have to be
> > changed to make this happen.
>
> - Find someway to handle the wide variety of interrupt controllers.
> - Be able to handle any multitude of V:P translations, including non-linear
> alongside linear transations.
> - Different PAGE_OFFSETs
> - Different kernel VM layouts allowing for a variety of different ioremap
> region sizes
Some of these could be handled by allowing building a seprate instance
for each platform compiled in. Maybe we could set them up with symlinks.
How about a minimal generic relocatable ARM kernel and then we load the
platform support as a module from ramdisk? :)
> and so the list goes on...
Yeah..
> > That way maybe you can wait a bit longer for the other defconfigs
> > and as an extra bonus I won't get flamed for removing these omap
> > defconfigs ;)
>
> Note that Linus is talking about removing all but one or two ARM
> defconfigs - which means your omap3_defconfig will probably be
> eventually culled.
Yes but I also think we need to do something about this.
Regards,
Tony
On Thu, 2010-06-03 at 13:31 -0700, Linus Torvalds wrote:
> and now you'd be able to basically generate a OMAP3EVM .config file by
> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
> only have to select the parts that are specific for the EVM platform,
> because the generic OMAP3 support would be picked by the Kconfig.omap3
> file, which in turn would not have to worry about the generic ARM parts
> etc.
>
> See?
We could just alias commands so when the user runs
"make ARCH=arm omap3_evm_defconfig"
it would just do whatever this command does ,
"KBUILD_KCONFIG=arch/arm/configs/Kconfig.omap3_evm make allnoconfig"
but those Kconfigs wouldn't be in "make menuconfig" it would just exist
to generate the defconfigs, or the .config .. So Kconfig.omap3_evm
basically becomes the defconfig.
That doesn't seem un-reasonable. Although the solver to me seems more
elegant and we're getting the solver for some other reasons it seems
(unrelated to this defconfig issue).
Daniel
On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <[email protected]> wrote:
> * Linus Torvalds <[email protected]> [100603 23:30]:
>>
>> and now you'd be able to basically generate a OMAP3EVM .config file by
>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
>> only have to select the parts that are specific for the EVM platform,
>> because the generic OMAP3 support would be picked by the Kconfig.omap3
>> file, which in turn would not have to worry about the generic ARM parts
>> etc.
>>
>> See?
>
> Sounds like a good improvment to me.
(as one who just finishing updating powerpc defconfigs...) ditto here.
I'd be happy to be rid of all the existing ppc defconfigs.
I like the Kconfig approach, but to be useful (at least for me) there
would need to be a way to get Kconfig to complain about things like
broken selects as in your example.
g.
On Fri, 2010-06-04 at 00:17 +0300, Tony Lindgren wrote:
> * Linus Torvalds <[email protected]> [100603 23:30]:
> >
> > and now you'd be able to basically generate a OMAP3EVM .config file by
> > just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
> > only have to select the parts that are specific for the EVM platform,
> > because the generic OMAP3 support would be picked by the Kconfig.omap3
> > file, which in turn would not have to worry about the generic ARM parts
> > etc.
> >
> > See?
>
> Sounds like a good improvment to me.
I was looking at this new defconfig added this merge window,
omap3_stalker_lks_defconig ..
diff -u arch/arm/configs/omap3_defconfig arch/arm/configs/omap3_stalker_lks_defconfig | diffstat
omap3_stalker_lks_defconfig | 850 +++++++-------------------------------------
1 file changed, 140 insertions(+), 710 deletions(-)
There's a lot of stuff that's different in there .. If I look through
it, there's stuff that's not related to OMAP , or even drivers. Like
Kprobes gets disabled over omap3_defconfig .
To me that's kind of messy .. It should really be just what the user
absolutely needs. I think we're able to get away with that now cause no
one cares enough to really read the defconfig and see what's going on.
Having stuff like that adds more flux.
Whatever scheme we go to would likely change that and people would
actually read what's going on. So we wouldn't be able to randomly have
Kprobes enabled in one config, and not enabled in another one. Or having
a debug config as one, then having a performance config for another.
Daniel
On Fri, 4 Jun 2010, Tony Lindgren wrote:
> * Russell King <[email protected]> [100603 21:07]:
> > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > > Compiling in multiple ARM platforms is trickier, we would have to get
> > > rid of the duplicate defines like NR_IRQS, then have some common clock
> > > framework etc. Then figure out some way to get rid of Makefile.boot.
> > > Russell probably has some other things in mind that would have to be
> > > changed to make this happen.
> >
> > - Find someway to handle the wide variety of interrupt controllers.
Eric Miao posted a patch series for that already.
> > - Be able to handle any multitude of V:P translations, including non-linear
> > alongside linear transations.
Some effort is being deployed at my $job to do that. Initially only the
linear translation will be supported, which should cover the vast
majority of the cases already. The odd targets will simply require a
build of their own like it is done today.
> > - Different PAGE_OFFSETs
Again, a majority of targets may simply share the default one.
> > - Different kernel VM layouts allowing for a variety of different ioremap
> > region sizes
VMALLOC_END should only need to become a per machine class variable
initialized at run time.
> Some of these could be handled by allowing building a seprate instance
> for each platform compiled in. Maybe we could set them up with symlinks.
We already have runtime selectable machine instances. Building multiple
machine class could extend on that.
> How about a minimal generic relocatable ARM kernel and then we load the
> platform support as a module from ramdisk? :)
Pity... Nah.
> > and so the list goes on...
>
> Yeah..
Like I said, there is an effort to gradually overcome those issues one
by one.
Nicolas
Russell King <[email protected]> writes:
> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
>> Compiling in multiple ARM platforms is trickier, we would have to get
>> rid of the duplicate defines like NR_IRQS, then have some common clock
>> framework etc. Then figure out some way to get rid of Makefile.boot.
>> Russell probably has some other things in mind that would have to be
>> changed to make this happen.
>
> - Find someway to handle the wide variety of interrupt controllers.
> - Be able to handle any multitude of V:P translations, including non-linear
> alongside linear transations.
> - Different PAGE_OFFSETs
> - Different kernel VM layouts allowing for a variety of different ioremap
> region sizes
>
> and so the list goes on...
>
- Support for ARMv5, v6 and v7 in the same kernel image.
On davinci, we've recently run into the problem where a new SoC in the
family is largely the same in terms of common HW blocks ands shared
peripherals with other davincis, but they upgraded from ARMv5 to
ARMv6. Attempting to build a single kernel that supports ARMv5 and
ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in
the same kernel.
Kevin
On Thu, Jun 03, 2010 at 01:31:07PM -0700, Linus Torvalds wrote:
> Now, the above is a _trivial_ one. And it's actually broken, because I
> should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT).
Seems to me that the brokenness of select is the main technical issue
stopping us getting rid of the defconfigs. If there was a way to tell
the Kconfig machinery "I want CONFIG_USB on, you figure out what has
to be enabled for that to make sense" then it would all work. But
that's a hard problem (and may possibly have multiple solutions).
Paul.
On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > Compiling in multiple ARM platforms is trickier, we would have to get
> > rid of the duplicate defines like NR_IRQS, then have some common clock
> > framework etc. Then figure out some way to get rid of Makefile.boot.
> > Russell probably has some other things in mind that would have to be
> > changed to make this happen.
Ok so multiple platforms in one kernel is a different subject and could
warrant a different thread. However it's interesting because we do that
quite well on powerpc :-)
(Note also that while the device-tree helps make it even easier, it's
not fundamentally necessary to achieve that goal).
> - Find someway to handle the wide variety of interrupt controllers.
We have a very nice and simple interrupt mapping scheme on powerpc that
makes that quite trivial along with the generic irq changes that went in
a couple of years ago (which we mostly based on ARM iirc).
We have a structure that define an interrupt numbering domain (which can
be associated 1:1 with a given controller but doesn't have to), and
simple APIs to allocate "linux" interrupt numbers associated with a
given domain/HW number pair. From there, we support multiple domains,
arbitrary layout and cascades, etc...
> - Be able to handle any multitude of V:P translations, including non-linear
> alongside linear transations.
For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore
spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic
patching would do nicely here though it's problematic with XIP kernels
(though my understanding is that those are getting less common).
> - Different PAGE_OFFSETs
Does this have to be a per SoC or mach family ? Users can change
PAGE_OFFSET on powerpc to change the user/kernel split (for example in
order to get more ioremap space or avoid turning on HIGHMEM) but it's in
the domain of the config and a kernel with a lower PAGE_OFFSET can
always boot all platforms even those that don't require it.
Alternatively, you can always try to do like we do on ppc64 with fully
runtime relocatable kernels :-)
> - Different kernel VM layouts allowing for a variety of different ioremap
> region sizes
>
> and so the list goes on...
That's quite easily done at runtime.
> > That way maybe you can wait a bit longer for the other defconfigs
> > and as an extra bonus I won't get flamed for removing these omap
> > defconfigs ;)
>
> Note that Linus is talking about removing all but one or two ARM
> defconfigs - which means your omap3_defconfig will probably be
> eventually culled.
Cheers,
Ben.
On Thu, 2010-06-03 at 20:57 +0100, Russell King wrote:
> config MACH_HALIBUT
> bool "Halibut Board (QCT SURF7201A)"
> select I2C if STD_CONFIG
> select I2C_WHATEVER if STD_CONFIG
> ...
>
> That means if you enable STD_CONFIG, you'll get everything that's required
> selected. If you then disable STD_CONFIG, I believe Kconfig leaves
> everything that was selected as still being selected.
>
> So, what you _could_ do is start off with a blank configuration, then
> configure a kernel with STD_CONFIG enabled and you end up with everything
> that's required. If you then want to disable something that's selected,
> turn off STD_CONFIG first, and you'll be able to turn off individual
> options.
The main problem with that approach is that you can't choose what is to
be modules and what is to be built-in.
Yes, I do -hate- modules as much as you do.
However, I have for example that little ARM based NAS box (DNS-323 from
Belkin) and the firmware on that thing won't let me boot a kernel that
is more than about 1.5M, tho I have about 6M of flash to put an
initramfs with modules in it.
Maybe we could extend select that way. IE. A way to say that a given
option should be y or m by default, for example, while the user can
still change it to be the other way around ?
Cheers,
Ben.
* Kevin Hilman <[email protected]> [100604 03:17]:
> Russell King <[email protected]> writes:
>
> > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> >> Compiling in multiple ARM platforms is trickier, we would have to get
> >> rid of the duplicate defines like NR_IRQS, then have some common clock
> >> framework etc. Then figure out some way to get rid of Makefile.boot.
> >> Russell probably has some other things in mind that would have to be
> >> changed to make this happen.
> >
> > - Find someway to handle the wide variety of interrupt controllers.
> > - Be able to handle any multitude of V:P translations, including non-linear
> > alongside linear transations.
> > - Different PAGE_OFFSETs
> > - Different kernel VM layouts allowing for a variety of different ioremap
> > region sizes
> >
> > and so the list goes on...
> >
>
> - Support for ARMv5, v6 and v7 in the same kernel image.
>
> On davinci, we've recently run into the problem where a new SoC in the
> family is largely the same in terms of common HW blocks ands shared
> peripherals with other davincis, but they upgraded from ARMv5 to
> ARMv6. Attempting to build a single kernel that supports ARMv5 and
> ARMv6 uncovered a pile of assumptions that v5 and v6 would never be in
> the same kernel.
Yeah we should sort that out, otherwise more things are slowly added
that makes it harder to do.
Regards,
Tony
* Nicolas Pitre <[email protected]> [100604 01:40]:
>
> Like I said, there is an effort to gradually overcome those issues one
> by one.
Unfortunately the same time we are slowly adding more and more ifdef else
code that adds new blockers to compile in multiple ARM platforms into
the same kernel. Some of the ones I've ran into over past few months are
CONFIG_HAS_TLS_REG, CONFIG_VFPv3 and CONFIG_SMP. The first two are
fixable though.
Anyways, once we get the TLS and VFPv3 issues sorted out, we
can do ARMv6 and ARMv7 booting binaries so I'll be able to whine
about any new blockers getting added :)
Regards,
Tony
On Fri, Jun 04, 2010 at 12:15:45AM +0200, ext Grant Likely wrote:
>On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <[email protected]> wrote:
>> * Linus Torvalds <[email protected]> [100603 23:30]:
>>>
>>> and now you'd be able to basically generate a OMAP3EVM .config file by
>>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
>>> only have to select the parts that are specific for the EVM platform,
>>> because the generic OMAP3 support would be picked by the Kconfig.omap3
>>> file, which in turn would not have to worry about the generic ARM parts
>>> etc.
>>>
>>> See?
>>
>> Sounds like a good improvment to me.
>
>(as one who just finishing updating powerpc defconfigs...) ditto here.
> I'd be happy to be rid of all the existing ppc defconfigs.
>
>I like the Kconfig approach, but to be useful (at least for me) there
>would need to be a way to get Kconfig to complain about things like
>broken selects as in your example.
Still selects needs to be improved so we have a 'select_module' option
that would make that driver a module instead of built-in.
--
balbi
DefectiveByDesign.org
* Benjamin Herrenschmidt <[email protected]> [100604 03:56]:
> On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
> > On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > > Compiling in multiple ARM platforms is trickier, we would have to get
> > > rid of the duplicate defines like NR_IRQS, then have some common clock
> > > framework etc. Then figure out some way to get rid of Makefile.boot.
> > > Russell probably has some other things in mind that would have to be
> > > changed to make this happen.
>
> Ok so multiple platforms in one kernel is a different subject and could
> warrant a different thread. However it's interesting because we do that
> quite well on powerpc :-)
>
> (Note also that while the device-tree helps make it even easier, it's
> not fundamentally necessary to achieve that goal).
Yeah both platform data and device tree should work just fine.
> > - Find someway to handle the wide variety of interrupt controllers.
>
> We have a very nice and simple interrupt mapping scheme on powerpc that
> makes that quite trivial along with the generic irq changes that went in
> a couple of years ago (which we mostly based on ARM iirc).
>
> We have a structure that define an interrupt numbering domain (which can
> be associated 1:1 with a given controller but doesn't have to), and
> simple APIs to allocate "linux" interrupt numbers associated with a
> given domain/HW number pair. From there, we support multiple domains,
> arbitrary layout and cascades, etc...
>
> > - Be able to handle any multitude of V:P translations, including non-linear
> > alongside linear transations.
>
> For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore
> spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic
> patching would do nicely here though it's problematic with XIP kernels
> (though my understanding is that those are getting less common).
>
> > - Different PAGE_OFFSETs
>
> Does this have to be a per SoC or mach family ? Users can change
> PAGE_OFFSET on powerpc to change the user/kernel split (for example in
> order to get more ioremap space or avoid turning on HIGHMEM) but it's in
> the domain of the config and a kernel with a lower PAGE_OFFSET can
> always boot all platforms even those that don't require it.
>
> Alternatively, you can always try to do like we do on ppc64 with fully
> runtime relocatable kernels :-)
>
> > - Different kernel VM layouts allowing for a variety of different ioremap
> > region sizes
> >
> > and so the list goes on...
>
> That's quite easily done at runtime.
Thanks for all the good info, that will be handy when trying to
figure out how to change things to support multiple ARM platforms.
Regards,
Tony
On Fri, Jun 4, 2010 at 03:02, Benjamin Herrenschmidt
<[email protected]> wrote:
> On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
>> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
>> > Compiling in multiple ARM platforms is trickier, we would have to get
>> > rid of the duplicate defines like NR_IRQS, then have some common clock
>> > framework etc. Then figure out some way to get rid of Makefile.boot.
>> > Russell probably has some other things in mind that would have to be
>> > changed to make this happen.
>
> Ok so multiple platforms in one kernel is a different subject and could
Supporting multiple platforms matters a lot to keep everything (not
just defconfigs)
under control.
Technically, on m68k we only need two defconfigs: sun3_defconfig (Sun 3 doesn't
use a Motorola MMU) and multi_defconfig (which is the logical OR of
all the other
defconfigs, and which should work on all non-Sun 3).
The reason we have the others is to ease building of platform-specific
kernels that
need less memory. I guess most of them can be (almost) regenerated from
multi_defconfig just by disabling support for the other platforms.
> warrant a different thread. However it's interesting because we do that
> quite well on powerpc :-)
So you could easily have one big common defconfig...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Jun 4, 2010 at 08:30, Geert Uytterhoeven <[email protected]> wrote:
> On Fri, Jun 4, 2010 at 03:02, Benjamin Herrenschmidt
> <[email protected]> wrote:
>> On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
>>> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
>>> > Compiling in multiple ARM platforms is trickier, we would have to get
>>> > rid of the duplicate defines like NR_IRQS, then have some common clock
>>> > framework etc. Then figure out some way to get rid of Makefile.boot.
>>> > Russell probably has some other things in mind that would have to be
>>> > changed to make this happen.
>>
>> Ok so multiple platforms in one kernel is a different subject and could
>
> Supporting multiple platforms matters a lot to keep everything (not just defconfigs)
> under control.
>
> Technically, on m68k we only need two defconfigs: sun3_defconfig (Sun 3 doesn't
> use a Motorola MMU) and multi_defconfig (which is the logical OR of all the other
> defconfigs, and which should work on all non-Sun 3).
Ah, I forgot...
But indeed, most of the churn when updating the defconfigs (hmm, it's
been a while I submitted an
update) is in the non-arch part: disabling zillions of new options we
don't want.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, 2010-06-04 at 08:30 +0200, Geert Uytterhoeven wrote:
>
> > warrant a different thread. However it's interesting because we do
> that
> > quite well on powerpc :-)
>
> So you could easily have one big common defconfig...
Well, there are things we still don't allow in one binary, and I suspect
it would be nasty on ARM too, such as widely different core arch (which
in ARM land would translate into widely different ARM architecture
version).
But yeah, we can pretty much make giant defconfigs. They are not very
useful tho. In the embedded world, size constraints are quite strong and
so you really need to be able to target only the subset of things you
want for some types of devices.
Of course, for things like ARM netbooks, it would be nice to have one
giant defconfig that boots them all, and that's probably an achievable
goal if the variants between bootloaders can be sorted out.
Cheers,
Ben.
Grant Likely <[email protected]> wrote:
> On Thu, Jun 3, 2010 at 3:17 PM, Tony Lindgren <[email protected]> wrote:
>> * Linus Torvalds <[email protected]> [100603 23:30]:
>>>
>>> and now you'd be able to basically generate a OMAP3EVM .config file by
>>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
>>> only have to select the parts that are specific for the EVM platform,
>>> because the generic OMAP3 support would be picked by the Kconfig.omap3
>>> file, which in turn would not have to worry about the generic ARM parts
>>> etc.
>>>
>>> See?
>>
>> Sounds like a good improvment to me.
>
> (as one who just finishing updating powerpc defconfigs...) ditto here.
> I'd be happy to be rid of all the existing ppc defconfigs.
>
> I like the Kconfig approach, but to be useful (at least for me) there
> would need to be a way to get Kconfig to complain about things like
> broken selects as in your example.
There was an attempt to fix this (I can re-post if people are interested):
http://lkml.org/lkml/2009/9/16/413
--
Catalin
On Thu, Jun 3, 2010 at 6:36 PM, Paul Mackerras <[email protected]> wrote:
> On Thu, Jun 03, 2010 at 01:31:07PM -0700, Linus Torvalds wrote:
>
>> Now, the above is a _trivial_ one. And it's actually broken, because I
>> should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT).
>
> Seems to me that the brokenness of select is the main technical issue
> stopping us getting rid of the defconfigs. ?If there was a way to tell
> the Kconfig machinery "I want CONFIG_USB on, you figure out what has
> to be enabled for that to make sense" then it would all work. ?But
> that's a hard problem (and may possibly have multiple solutions).
Yes, I think you're right. If select was 'smart', then the whole
issue kind of goes away. But as you say, that is a hard problem.
In the mean time, I'd be satisfied with a solution that punted out an
error at configure time if select requirements did not get met. I
should look at the patch Catalin posted.
g.
On Thu, Jun 3, 2010 at 11:31 PM, Linus Torvalds
<[email protected]> wrote:
> On Thu, 3 Jun 2010, Linus Torvalds wrote:
>>
>> I apparently haven't explained myself enough, because what you keep on
>> harping on is not something I consider acceptable.
>>
>> STD_CONFIG is pointless. It's pointless because the solution to what
>> you call STD_CONFIG would be to just NOT USING the special Kconfig.xyz
>> file at all.
>
> To make this _really_ concrete, let me actually give you an example (but
> broken and pointless) example Kconfig file, in order to _avoid_ having a
> def_config file.
>
> I do it by generating it. Let's say that I want a x86 configuration that
> has USB enabled. I can basically _ask_ the Kconfig machinery to generate
> that with something like this:
>
> - create a "Mykconfig" file:
>
> config MYCONFIG
> bool
> default y
> select USB
>
> source arch/x86/Kconfig
>
> and then I just do
>
> KBUILD_KCONFIG=Mykconfig make allnoconfig
>
> and look what appears in the .config file. In fact, do this:
>
> make allnoconfig
> cp .config no-config
> KBUILD_KCONFIG=Mykconfig make allnoconfig
> cp .config my-config
> diff -u no-config my-config
>
> to see the point of it all.
>
> Now, the above is a _trivial_ one. And it's actually broken, because I
> should not have forced CONFIG_USB (it depends on CONFIG_USB_SUPPORT).
And that's precisely the problem that his approach doesn't solve: dependencies.
---
config MYCONFIG
bool
default y
select MACH_OMAP3_BEAGLE
source arch/arm/Kconfig
---
Is the same as:
---
source arch/arm/Kconfig
---
With the SAT resolver it would be possible to have a .satconfig:
CONFIG_MACH_OMAP3_BEAGLE=y
And let the resolver figure everything out back from there.
--
Felipe Contreras
On Fri, Jun 4, 2010 at 12:17 AM, Tony Lindgren <[email protected]> wrote:
> * Linus Torvalds <[email protected]> [100603 23:30]:
>>
>> and now you'd be able to basically generate a OMAP3EVM .config file by
>> just running "allnoconfig" on that Kconfig.omap3_evm file. But it would
>> only have to select the parts that are specific for the EVM platform,
>> because the generic OMAP3 support would be picked by the Kconfig.omap3
>> file, which in turn would not have to worry about the generic ARM parts
>> etc.
>>
>> See?
>
> Sounds like a good improvment to me.
How about instead of using full defconfigs, we use minimal ones and
let the rest be determined with defaults.
For example, omap3_beagle.baseconfig would have something like:
CONFIG_MACH_OMAP3_BEAGLE=y
CONFIG_ARCH_OMAP=y
CONFIG_ARCH_OMAP3=y
CONFIG_ARCH_OMAP3430=y
CONFIG_AEABI=y
CONFIG_EMBEDDED=y
CONFIG_ARCH_OMAP_OTG=y
CONFIG_OMAP_MUX=n
CONFIG_OMAP_32K_TIMER=y
CONFIG_OMAP_DM_TIMER=y
CONFIG_INPUT_MOUSE=n
You copy that to the .config, and then do:
echo "" | make ARCH=arm oldconfig
The result would be exactly the same as we have now. With the SAT
resolver I think it should be possible to automatically simply the
current defconfigs. (CC'ing Vegard for comments)
I'm attaching a simplified base config, that I used to test this, and
the result is an exact match of the current omap3_beagle_defconfig.
--
Felipe Contreras
On Sat, 5 Jun 2010, Felipe Contreras wrote:
>
> How about instead of using full defconfigs, we use minimal ones and
> let the rest be determined with defaults.
I wouldn't mind that either, but there needs to be some way to check that
they _are_ minimal. Which is more complicated than even SAT, afaik.
So the reason I don't like the "minimal defconfig" notion is that a
"regular defconfig" will work equally well, and lazy people will thus not
bother to make it minimal (because it's work) and instead just pick the
full config output.
And we're all lazy. So gearing the process towards something that makes it
easy for lazy cases to do the wrong thing is a bad thing.
We also don't have any way to "source" these config files from each other,
so there's no way from within such a config file to say "use the basic
omap3 defaults an then just add this on top". You can do it by
concatenating several such files manually from the Makefile or whatever
script, of course, but then you end up with the files themselves not
actually describing what they do.
That's why I suggested the Kconfig format instead. It's the exact same
idea, but it's a "before pre-processing" format that already supports
including other files.
Linus
On Sat, Jun 5, 2010 at 5:39 PM, Linus Torvalds
<[email protected]> wrote:
> On Sat, 5 Jun 2010, Felipe Contreras wrote:
>>
>> How about instead of using full defconfigs, we use minimal ones and
>> let the rest be determined with defaults.
>
> I wouldn't mind that either, but there needs to be some way to check that
> they _are_ minimal. Which is more complicated than even SAT, afaik.
I don't think so. The SAT should be able to come up with a minimal
config for 'CONFIG_MACH_OMAP3_BEAGLE=y', and then a minimal config for
whatever is in omap3_beagle_defconfig. The diff is either unnecessary,
or the Kconfig files are missing some 'default y if whatever'. You fix
the Kconfig files, and then use the resulting minimal config.
> So the reason I don't like the "minimal defconfig" notion is that a
> "regular defconfig" will work equally well, and lazy people will thus not
> bother to make it minimal (because it's work) and instead just pick the
> full config output.
>
> And we're all lazy. So gearing the process towards something that makes it
> easy for lazy cases to do the wrong thing is a bad thing.
Yes, that's why I lean toward the solution that creates an ideal
config with the minimal effort: SAT with a single
CONFIG_MACH_OMAP3_BEAGLE=y. Then you don't need defconfigs at all.
> We also don't have any way to "source" these config files from each other,
> so there's no way from within such a config file to say "use the basic
> omap3 defaults an then just add this on top". You can do it by
> concatenating several such files manually from the Makefile or whatever
> script, of course, but then you end up with the files themselves not
> actually describing what they do.
I don't really see the big need for hierarchical configs. When you do
'make ARCH=arm' you are already including all the arm stuff, so
there's no need for an ARM base config. Then you would need some
platform stuff like OMAP3, but if you do CONFIG_ARCH_OMAP3=y, and
there are proper 'default y if ARCH_OMAP3' in the Kconfigs, you don't
need any base config either. The rest of the stuff is truly specific
to the boards.
If there's a need to include other configs, I'm sure we can come with
markups to include them and have a parser script that generates the
.config.
> That's why I suggested the Kconfig format instead. It's the exact same
> idea, but it's a "before pre-processing" format that already supports
> including other files.
Yes, although I don't like the format (it looks clearly designed for
something else), it's another possibility. However, I don't think
"allnoconfig" makes sense because that would ignore the default hints
already present in Kconfig files.
--
Felipe Contreras
On Thu, 3 Jun 2010, Russell King wrote:
> On Thu, Jun 03, 2010 at 11:18:05AM -0700, Linus Torvalds wrote:
>>
>>
>> On Thu, 3 Jun 2010, Russell King wrote:
>>>
>>> Umm. I don't think you've actually looked at the Kconfig files if you're
>>> writing this, because that's precisely what we already do.
>>
>> .. but if you do this _right_, then the defconfig files would be
>> unnecessary.
>>
>> That's my point. If you are right, then I can remove the defconfig files
>> entirely. Are you ready for that?
>
> Absolutely no way are we ready for that.
>
>> And if you aren't ready for that, then what was the point of your email?
>
> Linus, don't make this personal.
>
> The problem is NOT "what options which are found under the arch/arm tree
> do I need".
>
> The problem is "what options throughout the rest of the kernel do I need
> to result in a usable kernel".
What do you define as useable?
at two extremes:
do you mean a kernel that fully supports the board and all it's features?
do you mean a kernel that will compile and boot, but may not be able to
talk to the outside world as it doesn't know about any I/O that the chip
may have.
I don't think that defconfig can work for the first case (every single
system would hae it's own defconfig, which just doesn't scale)
and I'm not sure the second is very useful (and it should be covered by
the kconfig defaults)
if you are looking for something in between, where do you draw the line?
back when linux ran on x86 with IDE only, defconfig made a lot of sense,
but that was because the hardware was very standardized, nowdays even in
the x6 space there is enough variation that it's questionable how useful a
defconfig is.
What would be far better would be some tool that would take some hardware
defintition (either autodetecting from a currenlty running system on x86,
or from the device_tree stuff that's being worked on for other
architectures) and create a kernel config from that that would fully
support the hardware detected.
David Lang
> No amount of reorganising the Kconfig files into a heirarchial manner
> (which they already are) helps. Not one bit. Because they already are.
> That's not where the problem is.
>
> For instance, if I have platform A, I know it has an RTC. How do I know
> which of the 37 RTC drivers the kernel configuration presents me with to
> select? Am I really expected to open up the platform and read the
> device numbers off all the chips (some of which being surface mount are
> abbreviated) and work out that it's a TWL4030 RTC that I should be using?
>
> That's just one instance - and there's probably many more just like that.
> Just look at "multifunction drivers" for another case in point. How the
> hell do I know what multifunction driver is appropriate for a platform?
>
> Ditto "Power supply support".
>
> The list goes endlessly on. All those things I've mentioned are all
> _outside_ of arch/arm. That's where the _real_ problem is. Solve that
> problem so that it's easier for people to configure the kernel, and then
> we don't need the multitude defconfig files.
>
> That's the problem which the defconfigs are solving today.
>
>
On Thu, 3 Jun 2010, Russell King wrote:
> On Thu, Jun 03, 2010 at 11:20:30AM -0700, Daniel Walker wrote:
>> I don't see how we can do without defconfigs altogether tho. I mean , if
>> you want to run a Beagle board or a Nexus one we can't just give the
>> users a slim ARM config and let them troll through 1000's of drivers
>> trying to find just those ones that work on their given board.
>
> Well, Linus does have a point - I can't start a new with Kconfig and
> generate a working defconfig first time mainly because of the
> thounds of options there.
>
> What I can do is get the ARM side of the configuration right, since
> for the majority of cases the only thing that needs doing is selecting
> the platform class and the board itself.
>
> The problem comes with driver configuration, where you have to go
> through lots of menus to find all the drivers for the platform/SoC.
> That's the tedious bit, and more often than not it takes several
> attempts to get everything that's necessary.
Would the resulting kconfig files that Linus is proposing (or whatever
else goes in) be stable enough across different kernel versions that the
hardware vendors could create them when the hardware is created and make
them available?
I'm not just thinking the ARM embedded space here, I'm also thinking
things like laptops/notebooks which tend to have some unusual hardware as
well. having a 'this is enough to see everything on the system' config
would be a wonderful starting place to have.
David Lang
Daniel Walker <[email protected]> wrote:
> Have you noticed this ..
>
> http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130
>
> I'm not sure of the goals, but it sounds like it might be relevant.
In some cases you don't want to automatically enable features but rather
fix the Kconfig file. For example, with the select dependencies patch
(http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the
following:
warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects
CPU_32v6K which has unmet direct dependencies (CPU_V6)
Unless I misunderstand this, a solver may try to select CPU_V6 which I
don't want to. The solution is to fix Kconfig as below:
Author: Catalin Marinas <[email protected]>
Date: Wed Aug 12 13:50:05 2009 +0100
Mark CPU_32v6K as depended on CPU_V7
Signed-off-by: Catalin Marinas <[email protected]>
diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9f10a9b..a4909db 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -398,7 +398,7 @@ config CPU_V6
# ARMv6k
config CPU_32v6K
bool "Support ARM V6K processor extensions" if !SMP
- depends on CPU_V6
+ depends on CPU_V6 || CPU_V7
default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
help
Say Y here if your ARMv6 processor supports the 'K' extension.
--
Catalin
On Tue, 2010-06-08 at 16:30 +0100, Catalin Marinas wrote:
> Daniel Walker <[email protected]> wrote:
> > Have you noticed this ..
> >
> > http://ktrap.org/mailarchive/linux-kernel/2010/5/17/4571130
> >
> > I'm not sure of the goals, but it sounds like it might be relevant.
>
> In some cases you don't want to automatically enable features but rather
> fix the Kconfig file. For example, with the select dependencies patch
> (http://lkml.org/lkml/2009/9/16/413) on ARMv7 RealView I get the
> following:
>
> warning: (CPU_V7 && !ARCH_OMAP2 || CPU_MMP2 && ARCH_MMP) selects
> CPU_32v6K which has unmet direct dependencies (CPU_V6)
>
> Unless I misunderstand this, a solver may try to select CPU_V6 which I
> don't want to. The solution is to fix Kconfig as below:
It seems like those are something the solver would likely find, or have
problems with. Since we technically don't have a solver yet it's hard to
say what the end result would be. None the less it's sucks we have
things getting selected without their depends be met or correct..
Daniel
Hello,
[Added linux-arm-kernel ML to Cc, note that it's moderated for
non-subscribers.]
On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 3 Jun 2010, Daniel Walker wrote:
> >
> > I don't see how we can do without defconfigs altogether tho. I mean , if
> > you want to run a Beagle board or a Nexus one we can't just give the
> > users a slim ARM config and let them troll through 1000's of drivers
> > trying to find just those ones that work on their given board.
>
> Well, you also don't need the full defconfig's with the kernel.
>
> Right now they are just noise. They actually _hide_ things, because
> diffstat (and dirstat) information becomes pointless, and the diffs become
> totally unreadable by any human (trust me - when the choice is between
> "search for next relevant diff" or "blast it, I can't be bothered with
> walking through this crap", quite often the choice is the latter).
I wrote a script that throws out all unneeded lines in all arm
defconfigs that don't influence the resulting .config for .34 and
.35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced.
Here are the results:
$ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm
11.8% arch/arm/configs/
10.0% arch/arm/mach-msm/
10.8% arch/arm/mach-omap2/
4.8% arch/arm/mach-pxa/
4.5% arch/arm/mach-s5pc100/
3.3% arch/arm/mach-s5pv210/
4.4% arch/arm/mach-spear3xx/
3.1% arch/arm/mach-ux500/
5.1% arch/arm/plat-s5pc1xx/
3.1% arch/arm/plat-samsung/
38.2% arch/arm/
$ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm
3.1% arch/arm/mach-davinci/
11.3% arch/arm/mach-msm/
12.2% arch/arm/mach-omap2/
5.4% arch/arm/mach-pxa/
5.1% arch/arm/mach-s5pc100/
3.7% arch/arm/mach-s5pv210/
5.0% arch/arm/mach-spear3xx/
3.5% arch/arm/mach-ux500/
5.8% arch/arm/plat-s5pc1xx/
3.5% arch/arm/plat-samsung/
40.9% arch/arm/
$ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config
1.1% arch/arm/configs/
$ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1
177 files changed, 652 insertions(+), 194157 deletions(-)
(The insertions above are only moved lines I think, I didn't check them
all.)
The branches arm/defconfig/reduced-v2.6.34 and
arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at
git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at
http://git.pengutronix.de/?p=ukl/linux-2.6.git)
So maintaining these minimal defconfigs would have reduced the defconfig
noise from 11.8% down to 1.1%. And probably it could be considerably
reduced further with constructs like:
config HAVE_MTD_NAND_MXC
bool
config MTD_NAND_MXC
tristate "MXC NAND support"
...
default m if HAVE_MTD_NAND_MXC
help
...
...
config MACH_MX27ADS
...
select HAVE_MTD_NAND_MXC
. Compared with selecting everything in Kconfig files this approach
allows further tweaking of a config. (E.g. "I have a mx27ads machine,
but I don't need nand support.") Compared with the SAT-Solver it's an
idea that works today.
One downside of this approach (when done with my script only) is that
too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed.
This is OK from a logical POV but then changing the default of the
corresponding choice (and I intend to do that in the near future) would
break this defconfig.
I can share my script and I'm willing to support maintaining the
minimality of the defconfig files if they are an acceptable (maybe
intermediate) step for Linus.
Together with the efforts to reduce the number of defconfigs as thought
about in other mails of this thread the situation should become quite
better for Linus. (I'm currently working on merging support for all
Freescale SoCs into a single mach- directory and so merge mx1_defconfig,
mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and
mx51_defconfig.)
Linus: I would really appreciate if you wouldn't remove all (or nearly
all) defconfig files. I think you would force a quicker solution to
this problem, but during that time the ARM community would loose compile
coverage.
Thoughts on this?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi Linus,
I think my mail hit your inbox during your vacation. As this is quite
important for the ARM people and there isn't much time left, can you
please comment?
Thanks in advance
Uwe
On Mon, Jun 14, 2010 at 10:32:14AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
>
> [Added linux-arm-kernel ML to Cc, note that it's moderated for
> non-subscribers.]
>
> On Thu, Jun 03, 2010 at 11:21:59AM -0700, Linus Torvalds wrote:
> >
> >
> > On Thu, 3 Jun 2010, Daniel Walker wrote:
> > >
> > > I don't see how we can do without defconfigs altogether tho. I mean , if
> > > you want to run a Beagle board or a Nexus one we can't just give the
> > > users a slim ARM config and let them troll through 1000's of drivers
> > > trying to find just those ones that work on their given board.
> >
> > Well, you also don't need the full defconfig's with the kernel.
> >
> > Right now they are just noise. They actually _hide_ things, because
> > diffstat (and dirstat) information becomes pointless, and the diffs become
> > totally unreadable by any human (trust me - when the choice is between
> > "search for next relevant diff" or "blast it, I can't be bothered with
> > walking through this crap", quite often the choice is the latter).
> I wrote a script that throws out all unneeded lines in all arm
> defconfigs that don't influence the resulting .config for .34 and
> .35-rc1 and compared .34<->.35-rc with .34-reduced<->.35-rc1-reduced.
>
> Here are the results:
>
> $ git diff --dirstat v2.6.34 v2.6.35-rc1 arch/arm
> 11.8% arch/arm/configs/
> 10.0% arch/arm/mach-msm/
> 10.8% arch/arm/mach-omap2/
> 4.8% arch/arm/mach-pxa/
> 4.5% arch/arm/mach-s5pc100/
> 3.3% arch/arm/mach-s5pv210/
> 4.4% arch/arm/mach-spear3xx/
> 3.1% arch/arm/mach-ux500/
> 5.1% arch/arm/plat-s5pc1xx/
> 3.1% arch/arm/plat-samsung/
> 38.2% arch/arm/
>
> $ git diff --dirstat arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm
> 3.1% arch/arm/mach-davinci/
> 11.3% arch/arm/mach-msm/
> 12.2% arch/arm/mach-omap2/
> 5.4% arch/arm/mach-pxa/
> 5.1% arch/arm/mach-s5pc100/
> 3.7% arch/arm/mach-s5pv210/
> 5.0% arch/arm/mach-spear3xx/
> 3.5% arch/arm/mach-ux500/
> 5.8% arch/arm/plat-s5pc1xx/
> 3.5% arch/arm/plat-samsung/
> 40.9% arch/arm/
>
> $ git diff --dirstat=0 arm/defconfig/reduced-v2.6.34 arm/defconfig/reduced-v2.6.35-rc1 arch/arm | grep config
> 1.1% arch/arm/configs/
>
> $ git diff --shortstat v2.6.35-rc1 arm/defconfig/reduced-v2.6.35-rc1
> 177 files changed, 652 insertions(+), 194157 deletions(-)
>
> (The insertions above are only moved lines I think, I didn't check them
> all.)
>
> The branches arm/defconfig/reduced-v2.6.34 and
> arm/defconfig/reduced-v2.6.35-rc1 are available at my repo at
> git://git.pengutronix.de/git/ukl/linux-2.6.git . (There is a gitweb at
> http://git.pengutronix.de/?p=ukl/linux-2.6.git)
>
> So maintaining these minimal defconfigs would have reduced the defconfig
> noise from 11.8% down to 1.1%. And probably it could be considerably
> reduced further with constructs like:
>
> config HAVE_MTD_NAND_MXC
> bool
>
> config MTD_NAND_MXC
> tristate "MXC NAND support"
> ...
> default m if HAVE_MTD_NAND_MXC
> help
> ...
>
> ...
> config MACH_MX27ADS
> ...
> select HAVE_MTD_NAND_MXC
>
> . Compared with selecting everything in Kconfig files this approach
> allows further tweaking of a config. (E.g. "I have a mx27ads machine,
> but I don't need nand support.") Compared with the SAT-Solver it's an
> idea that works today.
>
> One downside of this approach (when done with my script only) is that
> too much is removed. E.g. in mx3_defconfig CONFIG_ARCH_MX3 is removed.
> This is OK from a logical POV but then changing the default of the
> corresponding choice (and I intend to do that in the near future) would
> break this defconfig.
>
> I can share my script and I'm willing to support maintaining the
> minimality of the defconfig files if they are an acceptable (maybe
> intermediate) step for Linus.
>
> Together with the efforts to reduce the number of defconfigs as thought
> about in other mails of this thread the situation should become quite
> better for Linus. (I'm currently working on merging support for all
> Freescale SoCs into a single mach- directory and so merge mx1_defconfig,
> mx21_defconfig, mx27_defconfig, mx31pdk_defconfig, mx3_defconfig and
> mx51_defconfig.)
>
> Linus: I would really appreciate if you wouldn't remove all (or nearly
> all) defconfig files. I think you would force a quicker solution to
> this problem, but during that time the ARM community would loose compile
> coverage.
>
> Thoughts on this?
>
> Best regards
> Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hi Linus,
On Wed, Jun 30, 2010 at 12:40:43PM +0200, Uwe Kleine-K?nig wrote:
> I think my mail hit your inbox during your vacation. As this is quite
> important for the ARM people and there isn't much time left, can you
> please comment?
As you havn't replied up to now I wonder if that just means that you
still plan to remove all defconfig files or if you are just busy doing
other things.
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
2010/7/12 Uwe Kleine-K?nig <[email protected]>:
>
> As you havn't replied up to now I wonder if that just means that you
> still plan to remove all defconfig files or if you are just busy doing
> other things.
The reason I haven't replied is that
(a) I don't think this really "solves" the issue, in that the
resulting files still aren't human-readable, and as such I suspect it
doesn't solve the problem in the long run: people will continue to
just run "make config" and then copy the resulting .config file as a
defconfig file.
and
(b) even if ARM were to go this way, and run the scripts to minimize
the defconfig files, that's not something _I_ would do. If I get tired
of seeing the insane pull requests where 90% of the crap is just
defconfig noise, then _my_ solution will be to remove the crap because
I simply am never going to be the person who maintains those defconfig
files.
See? Especially the "(b)" part is relevant - I am simply not going to
be the person who tries to clean up after other people sh*tting all
over their trees with defconfig files. If I do something, it will be
total surgery, ie "keep your damn broken defconfig files somewhere
else than in my tree - I'm tired of your stupidities". It will not be
"I'll be your mother and clean up your room every day after you made a
mess".
So if the ARM people decide that your script is a good way to clean up
the mess, I might be happy with that. But that would require that they
NEVER EVER try to push me a update that contains an un-cleaned-up
defconfig file. If they do, and the defconfig files end up showing up
big in git history, then the approach has failed.
See? The reason I'm not replying to your approach is that it's simply
not for me to do so (and no, I don't think it's maintainable, but I
haven't tried it, so..)
Linus
On Mon, Jul 12, 2010 at 09:51:47AM -0700, Linus Torvalds wrote:
> So if the ARM people decide that your script is a good way to clean up
> the mess, I might be happy with that. But that would require that they
> NEVER EVER try to push me a update that contains an un-cleaned-up
> defconfig file.
Does this mean that you aren't going to delete all the defconfigs
during the next merge window if we come up with an alternative
solution to yours?
When you brought up the problem you seemed absolutely convinced
that nothing except your solution was going to be acceptable.
On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
<[email protected]> wrote:
>
> When you brought up the problem you seemed absolutely convinced
> that nothing except your solution was going to be acceptable.
That's not true. What's true is that you didn't seem to _understand_
my solution, so I tried to push the understanding of it.
There are always other solutions. I seriously doubt that Uwe's is a
maintainable one. That said, even a one-time "reduce the size of that
stinking pile of sh*t" is probably better than nothing.
I hope you at least do agree that the current situation is a steaming
pile of sh*t. And yes, I _will_ remove the crap, both from POWER and
ARM, unless I see some serious tries at fixing it.
Linus
Hello Linus,
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> <[email protected]> wrote:
> >
> > When you brought up the problem you seemed absolutely convinced
> > that nothing except your solution was going to be acceptable.
>
> That's not true. What's true is that you didn't seem to _understand_
> my solution, so I tried to push the understanding of it.
>
> There are always other solutions. I seriously doubt that Uwe's is a
> maintainable one. That said, even a one-time "reduce the size of that
> stinking pile of sh*t" is probably better than nothing.
>
> I hope you at least do agree that the current situation is a steaming
> pile of sh*t. And yes, I _will_ remove the crap, both from POWER and
> ARM, unless I see some serious tries at fixing it.
I'm willing to try my solution, some others on the linux-arm-kernel
lists considered it worth trying, too. Feel free to pull my tree[1].
Russell refused to take defconfig changes for a while now, so I don't
expect merge problems if you do.
If it helps the powerpc people I can reduce their defconfigs, too.
Best regards
Uwe
[1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
are available in the git repository at:
git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1
Uwe Kleine-K?nig (1):
ARM: reduce defconfigs
arch/arm/configs/acs5k_defconfig | 1146 --------------
arch/arm/configs/acs5k_tiny_defconfig | 860 ----------
arch/arm/configs/afeb9260_defconfig | 1157 +--------------
arch/arm/configs/am200epdkit_defconfig | 1044 +------------
arch/arm/configs/am3517_evm_defconfig | 1250 ---------------
arch/arm/configs/ams_delta_defconfig | 1224 +--------------
arch/arm/configs/ap4evb_defconfig | 722 ---------
arch/arm/configs/assabet_defconfig | 862 +----------
arch/arm/configs/at572d940hfek_defconfig | 1318 +---------------
arch/arm/configs/at91cap9adk_defconfig | 1107 +-------------
arch/arm/configs/at91rm9200dk_defconfig | 955 +-----------
arch/arm/configs/at91rm9200ek_defconfig | 942 +-----------
arch/arm/configs/at91sam9260ek_defconfig | 958 +-----------
arch/arm/configs/at91sam9261ek_defconfig | 1087 +-------------
arch/arm/configs/at91sam9263ek_defconfig | 1103 +-------------
arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------
arch/arm/configs/at91sam9rlek_defconfig | 864 +----------
arch/arm/configs/ateb9200_defconfig | 1222 +--------------
arch/arm/configs/badge4_defconfig | 1178 +--------------
arch/arm/configs/bcmring_defconfig | 721 ---------
arch/arm/configs/cam60_defconfig | 1089 +-------------
arch/arm/configs/carmeva_defconfig | 696 +--------
arch/arm/configs/cerfcube_defconfig | 851 +----------
arch/arm/configs/cm_t35_defconfig | 1577 +------------------
arch/arm/configs/cm_x2xx_defconfig | 1774 +---------------------
arch/arm/configs/cm_x300_defconfig | 1565 ------------------
arch/arm/configs/cns3420vb_defconfig | 759 ---------
arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------
arch/arm/configs/colibri_pxa300_defconfig | 1082 -------------
arch/arm/configs/collie_defconfig | 887 +----------
arch/arm/configs/corgi_defconfig | 1621 +-------------------
arch/arm/configs/cpu9260_defconfig | 1225 +--------------
arch/arm/configs/cpu9g20_defconfig | 1215 +--------------
arch/arm/configs/cpuat91_defconfig | 1207 +--------------
arch/arm/configs/csb337_defconfig | 1113 +-------------
arch/arm/configs/csb637_defconfig | 1124 +-------------
arch/arm/configs/da8xx_omapl_defconfig | 1205 --------------
arch/arm/configs/davinci_all_defconfig | 1641 -------------------
arch/arm/configs/devkit8000_defconfig | 1732 +--------------------
arch/arm/configs/dove_defconfig | 1482 -----------------
arch/arm/configs/ebsa110_defconfig | 692 +--------
arch/arm/configs/ecbat91_defconfig | 1226 +--------------
arch/arm/configs/edb7211_defconfig | 554 +-------
arch/arm/configs/em_x270_defconfig | 1554 +------------------
arch/arm/configs/ep93xx_defconfig | 1340 ----------------
arch/arm/configs/eseries_pxa_defconfig | 1128 -------------
arch/arm/configs/ezx_defconfig | 1582 +-------------------
arch/arm/configs/footbridge_defconfig | 1185 +--------------
arch/arm/configs/fortunet_defconfig | 538 +-------
arch/arm/configs/g3evm_defconfig | 717 ---------
arch/arm/configs/g4evm_defconfig | 722 ---------
arch/arm/configs/h3600_defconfig | 1084 -------------
arch/arm/configs/h5000_defconfig | 917 +-----------
arch/arm/configs/h7201_defconfig | 542 +-------
arch/arm/configs/h7202_defconfig | 697 +--------
arch/arm/configs/hackkit_defconfig | 735 +---------
arch/arm/configs/htcherald_defconfig | 1073 +-------------
arch/arm/configs/igep0020_defconfig | 1467 -----------------
arch/arm/configs/imote2_defconfig | 1649 +-------------------
arch/arm/configs/integrator_defconfig | 817 +----------
arch/arm/configs/iop13xx_defconfig | 1061 +------------
arch/arm/configs/iop32x_defconfig | 1282 +---------------
arch/arm/configs/iop33x_defconfig | 1300 ---------------
arch/arm/configs/ixp2000_defconfig | 1024 +------------
arch/arm/configs/ixp23xx_defconfig | 1315 +---------------
arch/arm/configs/ixp4xx_defconfig | 1394 +----------------
arch/arm/configs/jornada720_defconfig | 1062 -------------
arch/arm/configs/kafa_defconfig | 830 +----------
arch/arm/configs/kb9202_defconfig | 1179 +--------------
arch/arm/configs/kirkwood_defconfig | 1700 --------------------
arch/arm/configs/ks8695_defconfig | 946 -----------
arch/arm/configs/lart_defconfig | 824 +----------
arch/arm/configs/loki_defconfig | 1028 +------------
arch/arm/configs/lpd270_defconfig | 968 +------------
arch/arm/configs/lpd7a400_defconfig | 835 +----------
arch/arm/configs/lpd7a404_defconfig | 1050 +------------
arch/arm/configs/lubbock_defconfig | 762 +---------
arch/arm/configs/lusl7200_defconfig | 436 +-----
arch/arm/configs/magician_defconfig | 1358 +----------------
arch/arm/configs/mainstone_defconfig | 755 +---------
arch/arm/configs/mini2440_defconfig | 1722 +--------------------
arch/arm/configs/mmp2_defconfig | 1135 -------------
arch/arm/configs/msm_defconfig | 830 +----------
arch/arm/configs/mv78xx0_defconfig | 1547 ------------------
arch/arm/configs/mx1_defconfig | 1018 +------------
arch/arm/configs/mx21_defconfig | 1072 -------------
arch/arm/configs/mx27_defconfig | 1152 --------------
arch/arm/configs/mx31pdk_defconfig | 728 ---------
arch/arm/configs/mx3_defconfig | 1089 -------------
arch/arm/configs/mx51_defconfig | 1130 -------------
arch/arm/configs/n770_defconfig | 1283 ---------------
arch/arm/configs/n8x0_defconfig | 1134 +-------------
arch/arm/configs/neocore926_defconfig | 1205 +--------------
arch/arm/configs/neponset_defconfig | 1081 +-------------
arch/arm/configs/netwinder_defconfig | 978 +------------
arch/arm/configs/netx_defconfig | 845 +----------
arch/arm/configs/nhk8815_defconfig | 1185 +--------------
arch/arm/configs/ns9xxx_defconfig | 23 -
arch/arm/configs/nuc910_defconfig | 844 ----------
arch/arm/configs/nuc950_defconfig | 896 -----------
arch/arm/configs/nuc960_defconfig | 855 ----------
arch/arm/configs/omap3_beagle_defconfig | 1258 +---------------
arch/arm/configs/omap3_defconfig | 1969 -----------------------
arch/arm/configs/omap3_evm_defconfig | 1429 +-----------------
arch/arm/configs/omap3_pandora_defconfig | 1640 +-------------------
arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------
arch/arm/configs/omap3_touchbook_defconfig | 1809 ---------------------
arch/arm/configs/omap_2430sdp_defconfig | 1181 +--------------
arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------
arch/arm/configs/omap_3630sdp_defconfig | 1456 -----------------
arch/arm/configs/omap_4430sdp_defconfig | 1157 --------------
arch/arm/configs/omap_apollon_2420_defconfig | 873 +----------
arch/arm/configs/omap_generic_1510_defconfig | 1089 +-------------
arch/arm/configs/omap_generic_1610_defconfig | 1092 +-------------
arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------
arch/arm/configs/omap_generic_2420_defconfig | 619 +--------
arch/arm/configs/omap_h2_1610_defconfig | 1234 +---------------
arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------
arch/arm/configs/omap_innovator_1510_defconfig | 1152 +--------------
arch/arm/configs/omap_innovator_1610_defconfig | 780 ---------
arch/arm/configs/omap_ldp_defconfig | 1124 -------------
arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------
arch/arm/configs/omap_perseus2_730_defconfig | 862 ----------
arch/arm/configs/omap_zoom2_defconfig | 1408 +-----------------
arch/arm/configs/omap_zoom3_defconfig | 1455 -----------------
arch/arm/configs/onearm_defconfig | 1067 +-------------
arch/arm/configs/orion5x_defconfig | 1693 --------------------
arch/arm/configs/overo_defconfig | 1621 +-------------------
arch/arm/configs/palmte_defconfig | 712 ---------
arch/arm/configs/palmtt_defconfig | 801 +----------
arch/arm/configs/palmz71_defconfig | 839 +----------
arch/arm/configs/palmz72_defconfig | 865 ----------
arch/arm/configs/pcm027_defconfig | 993 ------------
arch/arm/configs/picotux200_defconfig | 1207 +--------------
arch/arm/configs/pleb_defconfig | 712 +--------
arch/arm/configs/pnx4008_defconfig | 1286 +---------------
arch/arm/configs/pxa168_defconfig | 903 -----------
arch/arm/configs/pxa255-idp_defconfig | 753 +---------
arch/arm/configs/pxa3xx_defconfig | 1207 +--------------
arch/arm/configs/pxa910_defconfig | 820 ----------
arch/arm/configs/qil-a9260_defconfig | 1146 +--------------
arch/arm/configs/raumfeld_defconfig | 1690 --------------------
arch/arm/configs/realview-smp_defconfig | 1005 ------------
arch/arm/configs/realview_defconfig | 1001 ------------
arch/arm/configs/rpc_defconfig | 882 +-----------
arch/arm/configs/rx51_defconfig | 1648 +-------------------
arch/arm/configs/s3c2410_defconfig | 2018 ------------------------
arch/arm/configs/s3c6400_defconfig | 1445 -----------------
arch/arm/configs/s5p6440_defconfig | 947 -----------
arch/arm/configs/s5p6442_defconfig | 842 ----------
arch/arm/configs/s5pc100_defconfig | 977 ------------
arch/arm/configs/s5pc110_defconfig | 858 ----------
arch/arm/configs/s5pv210_defconfig | 861 ----------
arch/arm/configs/sam9_l9260_defconfig | 962 +-----------
arch/arm/configs/shannon_defconfig | 837 +----------
arch/arm/configs/shark_defconfig | 1167 --------------
arch/arm/configs/simpad_defconfig | 886 +----------
arch/arm/configs/spear300_defconfig | 722 ---------
arch/arm/configs/spear310_defconfig | 723 ---------
arch/arm/configs/spear320_defconfig | 723 ---------
arch/arm/configs/spear600_defconfig | 711 ---------
arch/arm/configs/spitz_defconfig | 1547 +------------------
arch/arm/configs/stamp9g20_defconfig | 1327 ----------------
arch/arm/configs/stmp378x_defconfig | 1014 +------------
arch/arm/configs/stmp37xx_defconfig | 895 +-----------
arch/arm/configs/sx1_defconfig | 1015 +------------
arch/arm/configs/tct_hammer_defconfig | 817 +----------
arch/arm/configs/trizeps4_defconfig | 1502 +-----------------
arch/arm/configs/u300_defconfig | 1118 -------------
arch/arm/configs/u8500_defconfig | 621 --------
arch/arm/configs/usb-a9260_defconfig | 1039 +------------
arch/arm/configs/usb-a9263_defconfig | 1031 +------------
arch/arm/configs/versatile_defconfig | 928 +-----------
arch/arm/configs/viper_defconfig | 1502 ------------------
arch/arm/configs/xcep_defconfig | 1031 +------------
arch/arm/configs/yl9200_defconfig | 1084 +-------------
arch/arm/configs/zeus_defconfig | 1842 ---------------------
177 files changed, 652 insertions(+), 194157 deletions(-)
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
2010/7/12 Uwe Kleine-K?nig <[email protected]>:
>
> I'm willing to try my solution, some others on the linux-arm-kernel
> lists considered it worth trying, too. ?Feel free to pull my tree[1].
> Russell refused to take defconfig changes for a while now, so I don't
> expect merge problems if you do.
Well, I can hardly refuse a pull that removes almost 200k lines. So
I'd happily pull it. Just this single line in your email is a very
very powerful thing:
> 177 files changed, 652 insertions(+), 194157 deletions(-)
However, before I would pull, I'd definitely like to make sure we at
least have some way forward too, and clarify some issues. So I have a
couple of questions:
- is this guaranteed to be a no-op as things stand now, and what are
the secondary effects of it?
Put another way: I realize that fairly late in the -rc series is
actually a really good time to do this, rather than during the merge
window itself when things are in flux. However, while it would be a
good time to pull this for that reason, it's also a _horrible_ time to
pull if it then regresses the defconfig uses, or if it causes horrible
problems for linux-next merging etc.
- what happens when somebody wants to update the defconfig files?
This is a question that involves a number of people, because over
the last half year, we've had lots of people changing them. "git
shortlog -ns" on that ARM config directory gives 39 people in the last
half year, with the top looking roughly like
26 Ben Dooks
10 Tony Lindgren
4 Haojian Zhuang
4 Kukjin Kim
3 Santosh Shilimkar
3 Sriram
2 Janusz Krzysztofik
....
and how are these people going to do their updates going forward
without re-introducing the noise?
IOW, I'd _love_ to get rid of almost 200k lines of noise and your
approach would seem to have the advantage that it's "invisible" to
users. But I would want to get some kind of assurance that it's
practical to do so.
Linus
On Mon, 12 Jul 2010, Uwe Kleine-K?nig wrote:
> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> > I hope you at least do agree that the current situation is a steaming
> > pile of sh*t. And yes, I _will_ remove the crap, both from POWER and
> > ARM, unless I see some serious tries at fixing it.
We all agree this is a pile of sh*t, as the truly valuable data is
drawned down into it. The diffstat numbers below certainly shows it
rather clearly.
Linus, please pull this git tree. This should functionally be a no op,
while giving us a better footing to develop a final solution.
> I'm willing to try my solution, some others on the linux-arm-kernel
> lists considered it worth trying, too. Feel free to pull my tree[1].
> Russell refused to take defconfig changes for a while now, so I don't
> expect merge problems if you do.
ACK.
> If it helps the powerpc people I can reduce their defconfigs, too.
>
> Best regards
> Uwe
>
> [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
>
> Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
>
> are available in the git repository at:
> git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1
>
> Uwe Kleine-K?nig (1):
> ARM: reduce defconfigs
>
> arch/arm/configs/acs5k_defconfig | 1146 --------------
> arch/arm/configs/acs5k_tiny_defconfig | 860 ----------
> arch/arm/configs/afeb9260_defconfig | 1157 +--------------
> arch/arm/configs/am200epdkit_defconfig | 1044 +------------
> arch/arm/configs/am3517_evm_defconfig | 1250 ---------------
> arch/arm/configs/ams_delta_defconfig | 1224 +--------------
> arch/arm/configs/ap4evb_defconfig | 722 ---------
> arch/arm/configs/assabet_defconfig | 862 +----------
> arch/arm/configs/at572d940hfek_defconfig | 1318 +---------------
> arch/arm/configs/at91cap9adk_defconfig | 1107 +-------------
> arch/arm/configs/at91rm9200dk_defconfig | 955 +-----------
> arch/arm/configs/at91rm9200ek_defconfig | 942 +-----------
> arch/arm/configs/at91sam9260ek_defconfig | 958 +-----------
> arch/arm/configs/at91sam9261ek_defconfig | 1087 +-------------
> arch/arm/configs/at91sam9263ek_defconfig | 1103 +-------------
> arch/arm/configs/at91sam9g20ek_defconfig | 1049 +------------
> arch/arm/configs/at91sam9rlek_defconfig | 864 +----------
> arch/arm/configs/ateb9200_defconfig | 1222 +--------------
> arch/arm/configs/badge4_defconfig | 1178 +--------------
> arch/arm/configs/bcmring_defconfig | 721 ---------
> arch/arm/configs/cam60_defconfig | 1089 +-------------
> arch/arm/configs/carmeva_defconfig | 696 +--------
> arch/arm/configs/cerfcube_defconfig | 851 +----------
> arch/arm/configs/cm_t35_defconfig | 1577 +------------------
> arch/arm/configs/cm_x2xx_defconfig | 1774 +---------------------
> arch/arm/configs/cm_x300_defconfig | 1565 ------------------
> arch/arm/configs/cns3420vb_defconfig | 759 ---------
> arch/arm/configs/colibri_pxa270_defconfig | 1556 ------------------
> arch/arm/configs/colibri_pxa300_defconfig | 1082 -------------
> arch/arm/configs/collie_defconfig | 887 +----------
> arch/arm/configs/corgi_defconfig | 1621 +-------------------
> arch/arm/configs/cpu9260_defconfig | 1225 +--------------
> arch/arm/configs/cpu9g20_defconfig | 1215 +--------------
> arch/arm/configs/cpuat91_defconfig | 1207 +--------------
> arch/arm/configs/csb337_defconfig | 1113 +-------------
> arch/arm/configs/csb637_defconfig | 1124 +-------------
> arch/arm/configs/da8xx_omapl_defconfig | 1205 --------------
> arch/arm/configs/davinci_all_defconfig | 1641 -------------------
> arch/arm/configs/devkit8000_defconfig | 1732 +--------------------
> arch/arm/configs/dove_defconfig | 1482 -----------------
> arch/arm/configs/ebsa110_defconfig | 692 +--------
> arch/arm/configs/ecbat91_defconfig | 1226 +--------------
> arch/arm/configs/edb7211_defconfig | 554 +-------
> arch/arm/configs/em_x270_defconfig | 1554 +------------------
> arch/arm/configs/ep93xx_defconfig | 1340 ----------------
> arch/arm/configs/eseries_pxa_defconfig | 1128 -------------
> arch/arm/configs/ezx_defconfig | 1582 +-------------------
> arch/arm/configs/footbridge_defconfig | 1185 +--------------
> arch/arm/configs/fortunet_defconfig | 538 +-------
> arch/arm/configs/g3evm_defconfig | 717 ---------
> arch/arm/configs/g4evm_defconfig | 722 ---------
> arch/arm/configs/h3600_defconfig | 1084 -------------
> arch/arm/configs/h5000_defconfig | 917 +-----------
> arch/arm/configs/h7201_defconfig | 542 +-------
> arch/arm/configs/h7202_defconfig | 697 +--------
> arch/arm/configs/hackkit_defconfig | 735 +---------
> arch/arm/configs/htcherald_defconfig | 1073 +-------------
> arch/arm/configs/igep0020_defconfig | 1467 -----------------
> arch/arm/configs/imote2_defconfig | 1649 +-------------------
> arch/arm/configs/integrator_defconfig | 817 +----------
> arch/arm/configs/iop13xx_defconfig | 1061 +------------
> arch/arm/configs/iop32x_defconfig | 1282 +---------------
> arch/arm/configs/iop33x_defconfig | 1300 ---------------
> arch/arm/configs/ixp2000_defconfig | 1024 +------------
> arch/arm/configs/ixp23xx_defconfig | 1315 +---------------
> arch/arm/configs/ixp4xx_defconfig | 1394 +----------------
> arch/arm/configs/jornada720_defconfig | 1062 -------------
> arch/arm/configs/kafa_defconfig | 830 +----------
> arch/arm/configs/kb9202_defconfig | 1179 +--------------
> arch/arm/configs/kirkwood_defconfig | 1700 --------------------
> arch/arm/configs/ks8695_defconfig | 946 -----------
> arch/arm/configs/lart_defconfig | 824 +----------
> arch/arm/configs/loki_defconfig | 1028 +------------
> arch/arm/configs/lpd270_defconfig | 968 +------------
> arch/arm/configs/lpd7a400_defconfig | 835 +----------
> arch/arm/configs/lpd7a404_defconfig | 1050 +------------
> arch/arm/configs/lubbock_defconfig | 762 +---------
> arch/arm/configs/lusl7200_defconfig | 436 +-----
> arch/arm/configs/magician_defconfig | 1358 +----------------
> arch/arm/configs/mainstone_defconfig | 755 +---------
> arch/arm/configs/mini2440_defconfig | 1722 +--------------------
> arch/arm/configs/mmp2_defconfig | 1135 -------------
> arch/arm/configs/msm_defconfig | 830 +----------
> arch/arm/configs/mv78xx0_defconfig | 1547 ------------------
> arch/arm/configs/mx1_defconfig | 1018 +------------
> arch/arm/configs/mx21_defconfig | 1072 -------------
> arch/arm/configs/mx27_defconfig | 1152 --------------
> arch/arm/configs/mx31pdk_defconfig | 728 ---------
> arch/arm/configs/mx3_defconfig | 1089 -------------
> arch/arm/configs/mx51_defconfig | 1130 -------------
> arch/arm/configs/n770_defconfig | 1283 ---------------
> arch/arm/configs/n8x0_defconfig | 1134 +-------------
> arch/arm/configs/neocore926_defconfig | 1205 +--------------
> arch/arm/configs/neponset_defconfig | 1081 +-------------
> arch/arm/configs/netwinder_defconfig | 978 +------------
> arch/arm/configs/netx_defconfig | 845 +----------
> arch/arm/configs/nhk8815_defconfig | 1185 +--------------
> arch/arm/configs/ns9xxx_defconfig | 23 -
> arch/arm/configs/nuc910_defconfig | 844 ----------
> arch/arm/configs/nuc950_defconfig | 896 -----------
> arch/arm/configs/nuc960_defconfig | 855 ----------
> arch/arm/configs/omap3_beagle_defconfig | 1258 +---------------
> arch/arm/configs/omap3_defconfig | 1969 -----------------------
> arch/arm/configs/omap3_evm_defconfig | 1429 +-----------------
> arch/arm/configs/omap3_pandora_defconfig | 1640 +-------------------
> arch/arm/configs/omap3_stalker_lks_defconfig | 1541 ------------------
> arch/arm/configs/omap3_touchbook_defconfig | 1809 ---------------------
> arch/arm/configs/omap_2430sdp_defconfig | 1181 +--------------
> arch/arm/configs/omap_3430sdp_defconfig | 1553 +------------------
> arch/arm/configs/omap_3630sdp_defconfig | 1456 -----------------
> arch/arm/configs/omap_4430sdp_defconfig | 1157 --------------
> arch/arm/configs/omap_apollon_2420_defconfig | 873 +----------
> arch/arm/configs/omap_generic_1510_defconfig | 1089 +-------------
> arch/arm/configs/omap_generic_1610_defconfig | 1092 +-------------
> arch/arm/configs/omap_generic_1710_defconfig | 1014 +------------
> arch/arm/configs/omap_generic_2420_defconfig | 619 +--------
> arch/arm/configs/omap_h2_1610_defconfig | 1234 +---------------
> arch/arm/configs/omap_h4_2420_defconfig | 1018 +------------
> arch/arm/configs/omap_innovator_1510_defconfig | 1152 +--------------
> arch/arm/configs/omap_innovator_1610_defconfig | 780 ---------
> arch/arm/configs/omap_ldp_defconfig | 1124 -------------
> arch/arm/configs/omap_osk_5912_defconfig | 1003 ------------
> arch/arm/configs/omap_perseus2_730_defconfig | 862 ----------
> arch/arm/configs/omap_zoom2_defconfig | 1408 +-----------------
> arch/arm/configs/omap_zoom3_defconfig | 1455 -----------------
> arch/arm/configs/onearm_defconfig | 1067 +-------------
> arch/arm/configs/orion5x_defconfig | 1693 --------------------
> arch/arm/configs/overo_defconfig | 1621 +-------------------
> arch/arm/configs/palmte_defconfig | 712 ---------
> arch/arm/configs/palmtt_defconfig | 801 +----------
> arch/arm/configs/palmz71_defconfig | 839 +----------
> arch/arm/configs/palmz72_defconfig | 865 ----------
> arch/arm/configs/pcm027_defconfig | 993 ------------
> arch/arm/configs/picotux200_defconfig | 1207 +--------------
> arch/arm/configs/pleb_defconfig | 712 +--------
> arch/arm/configs/pnx4008_defconfig | 1286 +---------------
> arch/arm/configs/pxa168_defconfig | 903 -----------
> arch/arm/configs/pxa255-idp_defconfig | 753 +---------
> arch/arm/configs/pxa3xx_defconfig | 1207 +--------------
> arch/arm/configs/pxa910_defconfig | 820 ----------
> arch/arm/configs/qil-a9260_defconfig | 1146 +--------------
> arch/arm/configs/raumfeld_defconfig | 1690 --------------------
> arch/arm/configs/realview-smp_defconfig | 1005 ------------
> arch/arm/configs/realview_defconfig | 1001 ------------
> arch/arm/configs/rpc_defconfig | 882 +-----------
> arch/arm/configs/rx51_defconfig | 1648 +-------------------
> arch/arm/configs/s3c2410_defconfig | 2018 ------------------------
> arch/arm/configs/s3c6400_defconfig | 1445 -----------------
> arch/arm/configs/s5p6440_defconfig | 947 -----------
> arch/arm/configs/s5p6442_defconfig | 842 ----------
> arch/arm/configs/s5pc100_defconfig | 977 ------------
> arch/arm/configs/s5pc110_defconfig | 858 ----------
> arch/arm/configs/s5pv210_defconfig | 861 ----------
> arch/arm/configs/sam9_l9260_defconfig | 962 +-----------
> arch/arm/configs/shannon_defconfig | 837 +----------
> arch/arm/configs/shark_defconfig | 1167 --------------
> arch/arm/configs/simpad_defconfig | 886 +----------
> arch/arm/configs/spear300_defconfig | 722 ---------
> arch/arm/configs/spear310_defconfig | 723 ---------
> arch/arm/configs/spear320_defconfig | 723 ---------
> arch/arm/configs/spear600_defconfig | 711 ---------
> arch/arm/configs/spitz_defconfig | 1547 +------------------
> arch/arm/configs/stamp9g20_defconfig | 1327 ----------------
> arch/arm/configs/stmp378x_defconfig | 1014 +------------
> arch/arm/configs/stmp37xx_defconfig | 895 +-----------
> arch/arm/configs/sx1_defconfig | 1015 +------------
> arch/arm/configs/tct_hammer_defconfig | 817 +----------
> arch/arm/configs/trizeps4_defconfig | 1502 +-----------------
> arch/arm/configs/u300_defconfig | 1118 -------------
> arch/arm/configs/u8500_defconfig | 621 --------
> arch/arm/configs/usb-a9260_defconfig | 1039 +------------
> arch/arm/configs/usb-a9263_defconfig | 1031 +------------
> arch/arm/configs/versatile_defconfig | 928 +-----------
> arch/arm/configs/viper_defconfig | 1502 ------------------
> arch/arm/configs/xcep_defconfig | 1031 +------------
> arch/arm/configs/yl9200_defconfig | 1084 +-------------
> arch/arm/configs/zeus_defconfig | 1842 ---------------------
> 177 files changed, 652 insertions(+), 194157 deletions(-)
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
On Mon, 12 Jul 2010, Linus Torvalds wrote:
> I'd happily pull it. Just this single line in your email is a very
> very powerful thing:
>
> > 177 files changed, 652 insertions(+), 194157 deletions(-)
>
> However, before I would pull, I'd definitely like to make sure we at
> least have some way forward too, and clarify some issues. So I have a
> couple of questions:
>
> - is this guaranteed to be a no-op as things stand now, and what are
> the secondary effects of it?
>
> Put another way: I realize that fairly late in the -rc series is
> actually a really good time to do this, rather than during the merge
> window itself when things are in flux. However, while it would be a
> good time to pull this for that reason, it's also a _horrible_ time to
> pull if it then regresses the defconfig uses, or if it causes horrible
> problems for linux-next merging etc.
This cannot be any worse than wholesale removal of those files as you
were contemplating at some point. Furthermore, on ARM we have someone
providing automatic rebuild of all defconfigs already, so any serious
issue should be noticed right away.
> - what happens when somebody wants to update the defconfig files?
>
> This is a question that involves a number of people, because over
> the last half year, we've had lots of people changing them. "git
> shortlog -ns" on that ARM config directory gives 39 people in the last
> half year, with the top looking roughly like
>
> 26 Ben Dooks
> 10 Tony Lindgren
> 4 Haojian Zhuang
> 4 Kukjin Kim
> 3 Santosh Shilimkar
> 3 Sriram
> 2 Janusz Krzysztofik
> ....
>
> and how are these people going to do their updates going forward
> without re-introducing the noise?
>
> IOW, I'd _love_ to get rid of almost 200k lines of noise and your
> approach would seem to have the advantage that it's "invisible" to
> users. But I would want to get some kind of assurance that it's
> practical to do so.
I think Uwe could provide his script and add it to the kernel tree.
Then all architectures could benefit from it. Having the defconfig
files contain only those options which are different from the defaults
is certainly more readable, even on x86.
Nicolas
On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
>>
>> ? ?Put another way: I realize that fairly late in the -rc series is
>> actually a really good time to do this, rather than during the merge
>> window itself when things are in flux. However, while it would be a
>> good time to pull this for that reason, it's also a _horrible_ time to
>> pull if it then regresses the defconfig uses, or if it causes horrible
>> problems for linux-next merging etc.
>
> This cannot be any worse than wholesale removal of those files as you
> were contemplating at some point. ?Furthermore, on ARM we have someone
> providing automatic rebuild of all defconfigs already, so any serious
> issue should be noticed right away.
You aren't really answering the question. The thing is, the wholesale
removal wouldn't happen during the late -rc anyway, and it wouldn't
cause any merge issues (merge conflicts where the file is just to be
removed are trivial to take care of).
So I'm really asking about the issue of "how does this work during the
late -rc phase". Where the _timing_ is the important thing.
Because I could as easily pull after 2.6.35 is out. That has it's own
downsides (with all the merging going on), but at the same time, it's
clearly the right time for a large change.
So when I ask about timing and "how does this work in late -rc", it's
really about how safe it is to do now. Because if it isn't very
obviously safe, I can't pull it.
One part of the "obviously safe" thing is verification for each
defconfig file that the end result is identical with the reduced
version. Uwe implied that it was, and that was clearly the intention,
but was there some explicit verification that yes, the
before-and-after configurations are 100% the same?
Also, I assume that while it's _mostly_ a transparent change to users,
it does require that people do "make oldconfig" with the reduced
defconfig file first, in order to avoid having to answer with the
defaults. No? And the reduced defconfig files obviously do depend on
the default in the Kconfig files themselves, so it does have that kind
of fairly subtle semantic change that may not be entirely obvious or
easy to notice.
So from a timing standpoint, I just want to be convinced that "late
-rc" really is the right thing. I'm not entirely sure it is, even
though I do see advantages.
> I think Uwe could provide his script and add it to the kernel tree.
> Then all architectures could benefit from it. ?Having the defconfig
> files contain only those options which are different from the defaults
> is certainly more readable, even on x86.
Quite possible. But maintainers would need to be on the lookout of
people actually using the script, and refusing to apply patches that
re-introduce the whole big thing.
I also haven't actually seen the script - I don't think Uwe ever
posted it - so maybe it's some very fragile thing. Hard to judge on no
real information ;^p
Linus
On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
<[email protected]> wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
>> I think Uwe could provide his script and add it to the kernel tree.
>> Then all architectures could benefit from it. ?Having the defconfig
>> files contain only those options which are different from the defaults
>> is certainly more readable, even on x86.
>
> Quite possible. But maintainers would need to be on the lookout of
> people actually using the script, and refusing to apply patches that
> re-introduce the whole big thing.
I can (partially) speak for powerpc. If ARM uses this approach, then
I think we can do the same. After the defconfigs are trimmed, I
certainly won't pick up any more full defconfigs.
Of course, I'm also operating under the assumption that this is a
temporary measure until one of the better solutions is implemented. I
do suspect that the trimmed defconfigs will tend to be unstable and
will still require manual maintenance. I think the Kconfig fragments
approach is the most promising if the dependencies issue can be
solved.
g.
Hi Linus,
On Mon, Jul 12, 2010 at 12:34:59PM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> >>
> >> ? ?Put another way: I realize that fairly late in the -rc series is
> >> actually a really good time to do this, rather than during the merge
> >> window itself when things are in flux. However, while it would be a
> >> good time to pull this for that reason, it's also a _horrible_ time to
> >> pull if it then regresses the defconfig uses, or if it causes horrible
> >> problems for linux-next merging etc.
> >
> > This cannot be any worse than wholesale removal of those files as you
> > were contemplating at some point. ?Furthermore, on ARM we have someone
> > providing automatic rebuild of all defconfigs already, so any serious
> > issue should be noticed right away.
>
> You aren't really answering the question. The thing is, the wholesale
> removal wouldn't happen during the late -rc anyway, and it wouldn't
> cause any merge issues (merge conflicts where the file is just to be
> removed are trivial to take care of).
>
> So I'm really asking about the issue of "how does this work during the
> late -rc phase". Where the _timing_ is the important thing.
>
> Because I could as easily pull after 2.6.35 is out. That has it's own
> downsides (with all the merging going on), but at the same time, it's
> clearly the right time for a large change.
I hoped you to pull this in during the merge window, but doing it now is
OK for me, too.
> So when I ask about timing and "how does this work in late -rc", it's
> really about how safe it is to do now. Because if it isn't very
> obviously safe, I can't pull it.
>
> One part of the "obviously safe" thing is verification for each
> defconfig file that the end result is identical with the reduced
> version. Uwe implied that it was, and that was clearly the intention,
> but was there some explicit verification that yes, the
> before-and-after configurations are 100% the same?
I'm pretty sure it's 100% save as I only kick a line in the defconfig if
the result doesn't change. Well, modulo bugs in my script. But now
that it's public you can convince yourself it's (hopefully) correct.
> Also, I assume that while it's _mostly_ a transparent change to users,
> it does require that people do "make oldconfig" with the reduced
> defconfig file first, in order to avoid having to answer with the
> defaults. No?
No, $(make ..._defconfig) is enough to get the full .config.
> And the reduced defconfig files obviously do depend on
> the default in the Kconfig files themselves, so it does have that kind
> of fairly subtle semantic change that may not be entirely obvious or
> easy to notice.
Right.
> So from a timing standpoint, I just want to be convinced that "late
> -rc" really is the right thing. I'm not entirely sure it is, even
> though I do see advantages.
>
> > I think Uwe could provide his script and add it to the kernel tree.
> > Then all architectures could benefit from it. ?Having the defconfig
> > files contain only those options which are different from the defaults
> > is certainly more readable, even on x86.
>
> Quite possible. But maintainers would need to be on the lookout of
> people actually using the script, and refusing to apply patches that
> re-introduce the whole big thing.
>
> I also haven't actually seen the script - I don't think Uwe ever
> posted it - so maybe it's some very fragile thing. Hard to judge on no
> real information ;^p
See attachment. It's just:
for each line:
kick $line if $(make ..._defconfig) results in the same config without $line
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> <[email protected]> wrote:
> >
> > When you brought up the problem you seemed absolutely convinced
> > that nothing except your solution was going to be acceptable.
>
> That's not true. What's true is that you didn't seem to _understand_
> my solution, so I tried to push the understanding of it.
That's your point of view.
My viewpoint was that I had read your email, thought of some alternative
solution, proposed it and the result was shot down without any apparant
thought about it. That gave the impression that you _only_ wanted to
see your own solution.
The result of that has been very little in the way of progress towards
either your, or my alternative solutions - and apart from a few Kconfig
corner quirk patches, the only major work that's happened has been from
Uwe.
So in that regard, I support Uwe's patches as a means to prevent the
impending loss of build coverage from facilities such as linux-next and
the ARM kernel autobuilder, as that's the only option that's currently
available.
As far as timing goes, I see no reason for it to be merged during -rc.
As has already been said, I'm intending _not_ to make the defconfig
situation any worse by accepting patches which add to the mess, as I'm
also mindful that its exactly those kinds of patches are the cause of
this problem.
Now, I'm happy to take Uwe's tree through mine for the next merge
window _iff_ you find his solution acceptable, and you want that to
happen.
I'll also use this opportunity to warn you now - especially as you also
complained about the amount of churn. There is an effort to try to
allow a single ARM kernel to boot on a wider range of platforms with
more differences than it currently does. This is going to mean a
certain amount of restructuring, and a lot of additional patches over
time to gradually convert the code. So, I'm expecting that there will
be even _more_ patches - some fairly big - to come over the next year
or so.
To give an idea - if we change the structure which defines a machine's
properties, we're going to be changing 348 files under arch/arm to match.
Clearly that's also going to give you a problem with diffstat being
swamped.
On Mon, 12 Jul 2010, Linus Torvalds wrote:
> On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> >>
> >> ? ?Put another way: I realize that fairly late in the -rc series is
> >> actually a really good time to do this, rather than during the merge
> >> window itself when things are in flux. However, while it would be a
> >> good time to pull this for that reason, it's also a _horrible_ time to
> >> pull if it then regresses the defconfig uses, or if it causes horrible
> >> problems for linux-next merging etc.
> >
> > This cannot be any worse than wholesale removal of those files as you
> > were contemplating at some point. ?Furthermore, on ARM we have someone
> > providing automatic rebuild of all defconfigs already, so any serious
> > issue should be noticed right away.
>
> You aren't really answering the question. The thing is, the wholesale
> removal wouldn't happen during the late -rc anyway, and it wouldn't
> cause any merge issues (merge conflicts where the file is just to be
> removed are trivial to take care of).
I'll answer for myself only. Others are free to pitch in if they have a
different opinion.
Since this issue came up, RMK refused to merge any changes to the
arch/arm/configs directory. Therefore a lot of those files aren't quite
up to date anymore anyway. We simply skipped the usual defconfig
updates that used to be sent around -rc4. And that's for the few
defconfig files that people cared to update. A bunch of less frequently
used targets are probably out of date since many kernel versions ago.
Those files are mainly used as a convenience for build testing. We tend
to cram as many profiles together as we can to limit the number of
different test builds. The remaining files are (supposed to be)
incompatible configurations. So I doubt anyone is using them verbatim
for deployed systems. If anything they should be reference
configurations not final product ones.
> So I'm really asking about the issue of "how does this work during the
> late -rc phase". Where the _timing_ is the important thing.
Given what I said above, I think that:
1) Those files aren't critical. They're damn useful indeed, but a
glitch in a defconfig file is far from being as important as a glitch
in the very code they refer to. So I don't think this is all that
critical if the pull is applied late in the -rc period.
2) Doing it sooner rather than later is IMHO the best thing to do. At
least we could now focus on maintaining and even improving on that
state rather than going on in circles wondering what to do with it.
People would be able to think about how to update their defconfig
files in the new form now instead of simply not updating it at all as
it has been the case for a while until something happens.
So to me this is all in favor for a merge before next merge window.
During the merge window this would create even more headaches.
> So when I ask about timing and "how does this work in late -rc", it's
> really about how safe it is to do now. Because if it isn't very
> obviously safe, I can't pull it.
As I said above, those files aren't that critical and no one should end
up in trouble if something is not exactly right after this merge. So
this makes it pretty safe to me.
> One part of the "obviously safe" thing is verification for each
> defconfig file that the end result is identical with the reduced
> version. Uwe implied that it was, and that was clearly the intention,
> but was there some explicit verification that yes, the
> before-and-after configurations are 100% the same?
I'll let Uwe answer this.
> Also, I assume that while it's _mostly_ a transparent change to users,
> it does require that people do "make oldconfig" with the reduced
> defconfig file first, in order to avoid having to answer with the
> defaults. No? And the reduced defconfig files obviously do depend on
> the default in the Kconfig files themselves, so it does have that kind
> of fairly subtle semantic change that may not be entirely obvious or
> easy to notice.
That is going to be the case regardless of the merge timing for this.
> So from a timing standpoint, I just want to be convinced that "late
> -rc" really is the right thing. I'm not entirely sure it is, even
> though I do see advantages.
I do too. At least this is positive progress for some bad issue that no
one could ever get very passionate about. Better keep the momentum.
> > I think Uwe could provide his script and add it to the kernel tree.
> > Then all architectures could benefit from it. ?Having the defconfig
> > files contain only those options which are different from the defaults
> > is certainly more readable, even on x86.
>
> Quite possible. But maintainers would need to be on the lookout of
> people actually using the script, and refusing to apply patches that
> re-introduce the whole big thing.
Pretty easy to see on the diffstat graph. Anyway, I'm sure once the
script is available then an army of kernel janitors will be busy trying
to find any transgressor.
> I also haven't actually seen the script - I don't think Uwe ever
> posted it - so maybe it's some very fragile thing. Hard to judge on no
> real information ;^p
I'm sure the script was quickly cobbled together as a proof of concept.
But once this defconfig reduction goes in then interest for a solid
script should raise significantly.
Nicolas
On Mon, 12 Jul 2010, Russell King - ARM Linux wrote:
> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
> > On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
> > <[email protected]> wrote:
> > >
> > > When you brought up the problem you seemed absolutely convinced
> > > that nothing except your solution was going to be acceptable.
> >
> > That's not true. What's true is that you didn't seem to _understand_
> > my solution, so I tried to push the understanding of it.
>
> That's your point of view.
>
> My viewpoint was that I had read your email, thought of some alternative
> solution, proposed it and the result was shot down without any apparant
> thought about it. That gave the impression that you _only_ wanted to
> see your own solution.
OK, please let's put this appearance of misunderstanding behind.
The rehashing of it from either parties doesn't produce any good.
> The result of that has been very little in the way of progress towards
> either your, or my alternative solutions - and apart from a few Kconfig
> corner quirk patches, the only major work that's happened has been from
> Uwe.
For the record, I do support Uwe's work too. I do wish it could go in
now so that from that point going forward we could only focus on
improving the thing instead of having to care about implications during
the merge window.
But I do prefer RMK's proposal in the long run. Not only is it more
expressive and clear, but it is easier to maintain going forward too.
But that transition cannot be automated and I doubt the majority of
targets will be converted anytime soon if at all. So at least Uwe's
reduction is quite a good compromise for those.
Nicolas
On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote:
>
> [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
>
> Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
>
> are available in the git repository at:
> git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1
BTW, looking at the most common entries in there, I think we might at some
point want to change some of the defaults in the respective Kconfig files.
Right now an empty defconfig would result in a configuration without
file system, networking or modules:
sort arch/arm/configs/* | uniq -c | sort -n | tail -n 30
114 CONFIG_BLK_DEV_RAM=y
116 CONFIG_BLK_DEV_INITRD=y
116 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
117 CONFIG_NFS_FS=y
118 CONFIG_MTD_CHAR=y
119 CONFIG_INOTIFY=y
122 # CONFIG_BLK_DEV_BSG is not set
122 CONFIG_IP_PNP=y
123 # CONFIG_IPV6 is not set
123 CONFIG_MTD_BLOCK=y
125 CONFIG_FPE_NWFPE=y
127 CONFIG_NET_ETHERNET=y
128 CONFIG_LOG_BUF_SHIFT=14
128 CONFIG_MTD=y
131 CONFIG_PACKET=y
132 # CONFIG_INPUT_MOUSE is not set
133 CONFIG_DEBUG_KERNEL=y
134 CONFIG_EXT2_FS=y
138 CONFIG_MODULE_UNLOAD=y
139 CONFIG_TMPFS=y
142 CONFIG_NETDEVICES=y
147 CONFIG_ZBOOT_ROM_BSS=0x0
147 CONFIG_ZBOOT_ROM_TEXT=0x0
151 CONFIG_INET=y
151 CONFIG_UNIX=y
153 CONFIG_NET=y
156 # CONFIG_VGA_CONSOLE is not set
158 CONFIG_MODULES=y
164 CONFIG_SYSVIPC=y
174 CONFIG_EXPERIMENTAL=y
Also, some of the defconfigs contain stuff that arguably does not belong
into a defconfig and could be removed in the next merge window, e.g.
ezx_defconfig:CONFIG_LOCALVERSION="-ezx200910312315"
pnx4008_defconfig:CONFIG_DECNET=m
at572d940hfek_defconfig:CONFIG_SGI_PARTITION=y
Arnd
On Mon, 12 Jul 2010, Arnd Bergmann wrote:
> On Monday 12 July 2010 20:50:29 Uwe Kleine-K?nig wrote:
> >
> > [1] The following changes since commit 67a3e12b05e055c0415c556a315a3d3eb637e29e:
> >
> > Linux 2.6.35-rc1 (2010-05-30 13:21:02 -0700)
> >
> > are available in the git repository at:
> > git://git.pengutronix.de/git/ukl/linux-2.6.git arm/defconfig/reduced-v2.6.35-rc1
>
> BTW, looking at the most common entries in there, I think we might at some
> point want to change some of the defaults in the respective Kconfig files.
> Right now an empty defconfig would result in a configuration without
> file system, networking or modules:
We need to come up with a scheme that allows for expressing the most
likely options you might want if you have machine x and/or machine y
selected. Those likely options are for drivers corresponding to
hardware soldered on the board or integrated into a SOC and therefore
which is not "optional". Right now this information is carried in the
defconfig files. Without that you need to lookup various datasheets and
wade through thousands of Kconfig options. Compared to that, stuff like
filesystems and networking protocols are optional items that currently
are more arbitrarily included into or excluded from the defconfig files.
I think that the first category of options should automatically be
selected on a per machine basis depending on BASE_CONFIG or the like and
expressed directly in the Kconfig files. Typically there are very few
of those (like a dozen or so for some example target I looked at).
Nicolas
On Mon, Jul 12, 2010 at 1:29 PM, Nicolas Pitre <[email protected]> wrote:
>
> For the record, I do support Uwe's work too. ?I do wish it could go in
> now so that from that point going forward we could only focus on
> improving the thing instead of having to care about implications during
> the merge window.
Ok, I merged it. I do love the diffstat. And while it may not be
optimal or a final solution, nobody seems to hate it either.
Linus
On Monday 12 July 2010 11:50:29 Uwe Kleine-K?nig wrote:
> If it helps the powerpc people I can reduce their defconfigs, too.
Do you have scripts or tools that you did this with, or is a manual
process. We're about to add several new (ARM) targets, and it'd be
nice to be able to make small defconfigs for those targets as well.
Thanks,
David
2010/7/12 David Brown <[email protected]>:
>
> Do you have scripts or tools that you did this with, or is a manual
> process. ?We're about to add several new (ARM) targets, and it'd be
> nice to be able to make small defconfigs for those targets as well.
Uwe posted it earlier in this thread as an attachement, and I put the
python script into the merge commit message too. And we should
probably put it somewhere in scripts too, and/or make a 'make' target
to create the small config files.
I pushed it all out, and tagged it as -rc5.
Linus
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
> 2010/7/12 David Brown <[email protected]>:
> >
> > Do you have scripts or tools that you did this with, or is a manual
> > process. We're about to add several new (ARM) targets, and it'd be
> > nice to be able to make small defconfigs for those targets as well.
>
> Uwe posted it earlier in this thread as an attachement, and I put the
> python script into the merge commit message too. And we should
> probably put it somewhere in scripts too, and/or make a 'make' target
> to create the small config files.
>
> I pushed it all out, and tagged it as -rc5.
Got it, thanks. I just pulled a bit soon.
It seems a bit brute force, probably not something I can make part of
our regular build process, but I can definitely run it before sending
patches out.
I wonder if there's a more efficient way of doing it that doesn't
involve invoking make for each line of the file. It at least
shouldn't be necessary to actually build the kernel each time.
David
On Mon, 12 Jul 2010, David Brown wrote:
> On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
>
> > 2010/7/12 David Brown <[email protected]>:
> > >
> > > Do you have scripts or tools that you did this with, or is a manual
> > > process. We're about to add several new (ARM) targets, and it'd be
> > > nice to be able to make small defconfigs for those targets as well.
> >
> > Uwe posted it earlier in this thread as an attachement, and I put the
> > python script into the merge commit message too. And we should
> > probably put it somewhere in scripts too, and/or make a 'make' target
> > to create the small config files.
> >
> > I pushed it all out, and tagged it as -rc5.
>
> Got it, thanks. I just pulled a bit soon.
>
> It seems a bit brute force, probably not something I can make part of
> our regular build process, but I can definitely run it before sending
> patches out.
>
> I wonder if there's a more efficient way of doing it that doesn't
> involve invoking make for each line of the file. It at least
> shouldn't be necessary to actually build the kernel each time.
I'm sure that some clever people will come up with a better script
eventually. Maybe this could even be generated by scripts/kconfig/conf
directly.
Nicolas
Hi
On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> <[email protected]> wrote:
> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> >> I think Uwe could provide his script and add it to the kernel tree.
> >> Then all architectures could benefit from it. ?Having the defconfig
> >> files contain only those options which are different from the defaults
> >> is certainly more readable, even on x86.
> >
> > Quite possible. But maintainers would need to be on the lookout of
> > people actually using the script, and refusing to apply patches that
> > re-introduce the whole big thing.
>
> I can (partially) speak for powerpc. If ARM uses this approach, then
> I think we can do the same. After the defconfigs are trimmed, I
> certainly won't pick up any more full defconfigs.
I just restarted my script on the powerpc defconfigs basing on rc5, I
assume they complete in a few days time.
> Of course, I'm also operating under the assumption that this is a
> temporary measure until one of the better solutions is implemented.
ack
> I
> do suspect that the trimmed defconfigs will tend to be unstable and
> will still require manual maintenance. I think the Kconfig fragments
> approach is the most promising if the dependencies issue can be
> solved.
I don't understand what you mean with unstable here. They are sensible
to changed defaults in the Kconfig files which you can consider to be
good or bad.
And ack, I like the Kconfig approach, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Hello,
On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > <[email protected]> wrote:
> > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> > >> I think Uwe could provide his script and add it to the kernel tree.
> > >> Then all architectures could benefit from it. ?Having the defconfig
> > >> files contain only those options which are different from the defaults
> > >> is certainly more readable, even on x86.
> > >
> > > Quite possible. But maintainers would need to be on the lookout of
> > > people actually using the script, and refusing to apply patches that
> > > re-introduce the whole big thing.
> >
> > I can (partially) speak for powerpc. If ARM uses this approach, then
> > I think we can do the same. After the defconfigs are trimmed, I
> > certainly won't pick up any more full defconfigs.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
So Stephen was faster than me. I don't know yet how he optimised my
script, meanwhile I put some efforts into it, too by just checking lines
that match "^(# )?CONFIG_".
Find it attached.
I will start to reduce the remaining configs (i.e. all but arm and
powerpc).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> > Hi
> >
> > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > <[email protected]> wrote:
> > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > >> Then all architectures could benefit from it. ?Having the defconfig
> > > >> files contain only those options which are different from the defaults
> > > >> is certainly more readable, even on x86.
> > > >
> > > > Quite possible. But maintainers would need to be on the lookout of
> > > > people actually using the script, and refusing to apply patches that
> > > > re-introduce the whole big thing.
> > >
> > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > I think we can do the same. After the defconfigs are trimmed, I
> > > certainly won't pick up any more full defconfigs.
> > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > assume they complete in a few days time.
> So Stephen was faster than me. I don't know yet how he optimised my
> script, meanwhile I put some efforts into it, too by just checking lines
> that match "^(# )?CONFIG_".
>
> Find it attached.
>
> I will start to reduce the remaining configs (i.e. all but arm and
> powerpc).
I added just a simple heuristic: If I could remove a line, I attempted
to remove twice the amount next time around (and fall back to 1 if it failed).
I.e. main loop:
i = 0
lines = 1
while i < len(config):
print 'test for %r + %d' % (config[i], lines)
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + lines:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
del config[i:i+lines]
lines *= 2
else:
if lines > 1:
lines = 1
else:
i += 1
I didn't measure what the actual improvement was, but I saw a fair amount
of 2/4/8-attempts passing, so I let it run. Stephen beat me to posting
the resulting patch though. :P
While this script is great, it is somewhat painful to run given that it
attempts one config per line. Even on a fast machine that tends to take
a while.
-Olof
2010/7/13 Uwe Kleine-K?nig <[email protected]>:
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
>> On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
>> <[email protected]> wrote:
>> > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
>> >> I think Uwe could provide his script and add it to the kernel tree.
>> >> Then all architectures could benefit from it. ?Having the defconfig
>> >> files contain only those options which are different from the defaults
>> >> is certainly more readable, even on x86.
>> >
>> > Quite possible. But maintainers would need to be on the lookout of
>> > people actually using the script, and refusing to apply patches that
>> > re-introduce the whole big thing.
>>
>> I can (partially) speak for powerpc. ?If ARM uses this approach, then
>> I think we can do the same. ?After the defconfigs are trimmed, I
>> certainly won't pick up any more full defconfigs.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
>
>> Of course, I'm also operating under the assumption that this is a
>> temporary measure until one of the better solutions is implemented.
> ack
>
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?I
>> do suspect that the trimmed defconfigs will tend to be unstable and
>> will still require manual maintenance. ?I think the Kconfig fragments
>> approach is the most promising if the dependencies issue can be
>> solved.
> I don't understand what you mean with unstable here. ?They are sensible
> to changed defaults in the Kconfig files which you can consider to be
> good or bad.
With the trimmed config, changes to default settings on config items
will immediately picked up regardless of whether or not it was wanted,
and potentially disabling things that were explicitly selected in
defconfig. But thinking about it more, that isn't really any worse
than the old situation where defconfigs always override Kconfig
defaults. So either way, defconfigs are simply a broken concept.
> And ack, I like the Kconfig approach, too.
Yeah, the problem goes away with Kconfig fragments. A programmer can
then explicitly state which CONFIG values need to be overridden.
g.
On Monday 12 July 2010 18:18:01 Linus Torvalds wrote:
> 2010/7/12 David Brown <[email protected]>:
> > Do you have scripts or tools that you did this with, or is a manual
> > process. We're about to add several new (ARM) targets, and it'd be
> > nice to be able to make small defconfigs for those targets as well.
>
> Uwe posted it earlier in this thread as an attachement, and I put the
> python script into the merge commit message too. And we should
> probably put it somewhere in scripts too, and/or make a 'make' target
> to create the small config files.
>
> I pushed it all out, and tagged it as -rc5.
FYI, I repeatedly submitted a bash script to do this back in 2005, with
documentation and makefile changes to call it and so on.
http://lwn.net/Articles/161086/
The current version of that script is is in my mercurial archive here:
http://impactlinux.com/hg/hgwebdir.cgi/aboriginal/file/tip/sources/toys/miniconfig.sh
I'm still using it in my Aboriginal Linux project. (Not just for the kernel,
but for busybox and uClibc too.)
Attached are miniconfigs I use for a dozen or so QEMU targets. (The project is
trying to build kernels aimed at every qemu system emulation. I've got maybe
2/3 of them so far. Arm, mips, sh4, x86, x86_64, sparc...)
They're used to create the system-image tarballs here:
http://impactlinux.com/aboriginal/downloads/binaries/
You can download that for that target that interests you, extract it, and use
run-emulator.sh to launch it under qemu. I have a cron job that does cross-
platform regression testing, spitting /dev/console to a log file on the host.
By the way, my build is generating those miniconfigs via a common "baseconfig"
file to which I append the target-specific stuff. For example, my current
baseconfig is:
CONFIG_EXPERIMENTAL=y
CONFIG_NO_HZ=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_PCI=y
CONFIG_BINFMT_ELF=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IDE=y
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_NET_PCI=y
CONFIG_8139CP=y
CONFIG_HW_RANDOM=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_DEV=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_TMPFS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_SQUASHFS=y
CONFIG_MAGIC_SYSRQ=y
Then for mips I append:
CONFIG_MIPS_MALTA=y
CONFIG_CPU_MIPS32_R2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
#CONFIG_PM=y
CONFIG_PCNET32=y
CONFIG_BLK_DEV_PIIX=y
Or for x86_64 it's:
CONFIG_ACPI=y
CONFIG_BLK_DEV_PIIX=y
CONFIG_NETDEV_1000=y
CONFIG_E1000=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
And for armv4tl it's this big long saga (yes, with comments):
# Processor config
# QEMU patch: http://www.mail-archive.com/[email protected]/msg19370.html
# and QEMU option '-cpu arm920t' enable CONFIG_CPU_ARM920T=y which is the
# processor that actually _needs_ this code. But until then, qemu can only
# emulate an armv5 CPU...
CONFIG_CPU_ARM926T=y
CONFIG_MMU=y
CONFIG_VFP=y
CONFIG_ARM_THUMB=y
CONFIG_AEABI=y
# Versatile board
CONFIG_ARCH_VERSATILE_PB=y
CONFIG_PCI_LEGACY=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
CONFIG_RTC_DRV_PL031=y
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_SYM53C8XX_MMIO=y
Rob
--
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
On Tue, 13 Jul 2010, Olof Johansson wrote:
> On Tue, Jul 13, 2010 at 10:07:05AM +0200, Uwe Kleine-K?nig wrote:
> > Hello,
> >
> > On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-K?nig wrote:
> > > Hi
> > >
> > > On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > > > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > > > <[email protected]> wrote:
> > > > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <[email protected]> wrote:
> > > > >> I think Uwe could provide his script and add it to the kernel tree.
> > > > >> Then all architectures could benefit from it. ?Having the defconfig
> > > > >> files contain only those options which are different from the defaults
> > > > >> is certainly more readable, even on x86.
> > > > >
> > > > > Quite possible. But maintainers would need to be on the lookout of
> > > > > people actually using the script, and refusing to apply patches that
> > > > > re-introduce the whole big thing.
> > > >
> > > > I can (partially) speak for powerpc. If ARM uses this approach, then
> > > > I think we can do the same. After the defconfigs are trimmed, I
> > > > certainly won't pick up any more full defconfigs.
> > > I just restarted my script on the powerpc defconfigs basing on rc5, I
> > > assume they complete in a few days time.
> > So Stephen was faster than me. I don't know yet how he optimised my
> > script, meanwhile I put some efforts into it, too by just checking lines
> > that match "^(# )?CONFIG_".
> >
> > Find it attached.
> >
> > I will start to reduce the remaining configs (i.e. all but arm and
> > powerpc).
>
> I added just a simple heuristic: If I could remove a line, I attempted
> to remove twice the amount next time around (and fall back to 1 if it failed).
>
[...]
>
> While this script is great, it is somewhat painful to run given that it
> attempts one config per line. Even on a fast machine that tends to take
> a while.
The optimal solution is to add that .config reduction ability straight
into the Kconfig parser (scripts/kconfig/*). There you can find out
right away what are the non default state for each config option without
actually trying them out one by one.
Nicolas
On Tue, Jul 13, 2010 at 2:34 AM, David Brown <[email protected]> wrote:
> It seems a bit brute force, probably not something I can make part of
> our regular build process, but I can definitely run it before sending
> patches out.
>
> I wonder if there's a more efficient way of doing it that doesn't
> involve invoking make for each line of the file. It at least
> shouldn't be necessary to actually build the kernel each time.
Yes, I think there's a more efficient way to do it, but it would
require the SAT resolver, or something like that.
--
Felipe Contreras
On Mon, Jul 12, 2010 at 11:06 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Mon, Jul 12, 2010 at 10:40:36AM -0700, Linus Torvalds wrote:
>> On Mon, Jul 12, 2010 at 10:32 AM, Russell King - ARM Linux
>> <[email protected]> wrote:
>> >
>> > When you brought up the problem you seemed absolutely convinced
>> > that nothing except your solution was going to be acceptable.
>>
>> That's not true. What's true is that you didn't seem to _understand_
>> my solution, so I tried to push the understanding of it.
>
> That's your point of view.
>
> My viewpoint was that I had read your email, thought of some alternative
> solution, proposed it and the result was shot down without any apparant
> thought about it. That gave the impression that you _only_ wanted to
> see your own solution.
I think you got it wrong. Linus liked my proposal of minimal
defconfigs, and the only discrepancy was on the format:
http://article.gmane.org/gmane.linux.kernel/995419
--
Felipe Contreras
On Mon, Jul 12, 2010 at 04:34:04PM -0700, David Brown wrote:
> On Monday 12 July 2010 16:18:01 Linus Torvalds wrote:
>
> > 2010/7/12 David Brown <[email protected]>:
> > >
> > > Do you have scripts or tools that you did this with, or is a manual
> > > process. We're about to add several new (ARM) targets, and it'd be
> > > nice to be able to make small defconfigs for those targets as well.
> >
> > Uwe posted it earlier in this thread as an attachement, and I put the
> > python script into the merge commit message too. And we should
> > probably put it somewhere in scripts too, and/or make a 'make' target
> > to create the small config files.
> >
> > I pushed it all out, and tagged it as -rc5.
>
> Got it, thanks. I just pulled a bit soon.
>
> It seems a bit brute force, probably not something I can make part of
> our regular build process, but I can definitely run it before sending
> patches out.
>
> I wonder if there's a more efficient way of doing it that doesn't
> involve invoking make for each line of the file. It at least
> shouldn't be necessary to actually build the kernel each time.
Note that no kernel is built at all, only the config is regenerated once
for each line.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
2010/7/14 Uwe Kleine-K?nig <[email protected]>:
> Note that no kernel is built at all, only the config is regenerated once
> for each line.
You could special case blank lines and comments (other than ones
like "# CONFIG_FOO is not set" which do matter). They account for
~15% of the lines in my .config files. But it probably doesn't matter
all that much. I just ran reduce_defconfig in parallel on all the ia64
defconfig files (in separate build trees) and they were all done when
I looked back an hour or so later. Nice tool!
-Tony