Heads up: Linus plans to kill ARM defconfigs

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

The subject says everything you need to know.  Randy provided this
link earlier:

  http://lkml.org/lkml/2010/6/2/472

Linus doesn't appear to be listening to reason, so I see now this as
a fait accompli.  It'll apparantly happen at the next merge window.

So, don't send anything which contains a defconfig file or updates to
it.  It's pointless.

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne ?t 3. ?ervna 2010 21:24:59 Russell King - ARM Linux napsal(a):
> The subject says everything you need to know.  Randy provided this
> link earlier:
> 
>   http://lkml.org/lkml/2010/6/2/472
> 
> Linus doesn't appear to be listening to reason, so I see now this as
> a fait accompli.  It'll apparantly happen at the next merge window.

The defconfigs age ... there's no point keeping them. They'll be useless crap 
unless someone updates them often anyway.

Maybe adding a Kconfig option that's select all the default stuff the platform 
needs would be a way to go ? (that was already proposed there)

> 
> So, don't send anything which contains a defconfig file or updates to
> it.  It's pointless.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Thu, Jun 03, 2010 at 09:55:19PM +0200, Marek Vasut wrote:
> Dne ?t 3. ?ervna 2010 21:24:59 Russell King - ARM Linux napsal(a):
> > The subject says everything you need to know.  Randy provided this
> > link earlier:
> > 
> >   http://lkml.org/lkml/2010/6/2/472
> > 
> > Linus doesn't appear to be listening to reason, so I see now this as
> > a fait accompli.  It'll apparantly happen at the next merge window.
> 
> The defconfigs age ... there's no point keeping them. They'll be useless crap 
> unless someone updates them often anyway.
> 
> Maybe adding a Kconfig option that's select all the default stuff the platform 
> needs would be a way to go ? (that was already proposed there)

The problem comes (as Daniel pointed out _after_ my suggested solution to
this problem) is if you want to turn off something that's 'selected' in
this way.

Anyway, let's not start a new lengthy thread on the subject here; it won't
have much effect being only on this list.

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne ?t 3. ?ervna 2010 22:01:09 Russell King - ARM Linux napsal(a):
> On Thu, Jun 03, 2010 at 09:55:19PM +0200, Marek Vasut wrote:
> > Dne ?t 3. ?ervna 2010 21:24:59 Russell King - ARM Linux napsal(a):
> > > The subject says everything you need to know.  Randy provided this
> > > 
> > > link earlier:
> > >   http://lkml.org/lkml/2010/6/2/472
> > > 
> > > Linus doesn't appear to be listening to reason, so I see now this as
> > > a fait accompli.  It'll apparantly happen at the next merge window.
> > 
> > The defconfigs age ... there's no point keeping them. They'll be useless
> > crap unless someone updates them often anyway.
> > 
> > Maybe adding a Kconfig option that's select all the default stuff the
> > platform needs would be a way to go ? (that was already proposed there)
> 
> The problem comes (as Daniel pointed out _after_ my suggested solution to
> this problem) is if you want to turn off something that's 'selected' in
> this way.

Yup, I got the point.
> 
> Anyway, let's not start a new lengthy thread on the subject here; it won't
> have much effect being only on this list.

Just as Nicolas pointed out, we need a solution. I guess lenghty thread is 
unavoidable, sorry. If possible, could you CC interested parties ?

btw. Maybe updating the machine registry so it allows pasting/attaching a 
defconfig with information about kernel version the defconfig corresponds with ?

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Thu, 3 Jun 2010, Marek Vasut wrote:

> > Anyway, let's not start a new lengthy thread on the subject here; it won't
> > have much effect being only on this list.
> 
> Just as Nicolas pointed out, we need a solution. I guess lenghty thread is 
> unavoidable, sorry. If possible, could you CC interested parties ?

The discussion is happening on linux-kernel at vger.kernel.org.  Please 
feel free to contribute to the thread over there.  You don't need to be 
subscribed to post.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Thu, Jun 03, 2010 at 10:27:56PM +0200, Marek Vasut wrote:
> btw. Maybe updating the machine registry so it allows pasting/attaching a 
> defconfig with information about kernel version the defconfig corresponds
> with ?

That means persisting with defconfigs, and the problems of keeping
them updated with the kernel.

Moreover, it encourages "one defconfig per machine", which will
cause the number of defconfigs to grow even more - and I don't see
such a system being usable with kautobuild.

Given that it'd mean we still need to solve the problem, I don't see
much point in expanding the machine database to store defconfigs.  It
seems to me it only moves the problem elsewhere, and at the same time
means we end up with two concurrently running systems - the fixed
in-kernel method and the external defconfig file.

Heads up: Linus plans to kill ARM defconfigs

[Daniel Walker]

On Thu, 2010-06-03 at 21:01 +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 03, 2010 at 09:55:19PM +0200, Marek Vasut wrote:
> > Dne ?t 3. ?ervna 2010 21:24:59 Russell King - ARM Linux napsal(a):
> > > The subject says everything you need to know.  Randy provided this
> > > link earlier:
> > > 
> > >   http://lkml.org/lkml/2010/6/2/472
> > > 
> > > Linus doesn't appear to be listening to reason, so I see now this as
> > > a fait accompli.  It'll apparantly happen at the next merge window.
> > 
> > The defconfigs age ... there's no point keeping them. They'll be useless crap 
> > unless someone updates them often anyway.
> > 
> > Maybe adding a Kconfig option that's select all the default stuff the platform 
> > needs would be a way to go ? (that was already proposed there)
> 
> The problem comes (as Daniel pointed out _after_ my suggested solution to
> this problem) is if you want to turn off something that's 'selected' in
> this way.
> 
> Anyway, let's not start a new lengthy thread on the subject here; it won't
> have much effect being only on this list.

I think Linus was suggesting that we create Kconfig files that are
strictly used to generate .config files for certain platforms.

So his proposal was to encode everything into Kconfig files, but those
Kconfig options we use don't show up in "make menuconfig" .. so the
whole notion of things not getting unselected doesn't really matter, we
wouldn't end up dealing with it.

You would just generate the .config for whatever sub-architecture you
need, then run "make menuconfig" and select or de-select whatever else
you want.

Daniel

Heads up: Linus plans to kill ARM defconfigs

[Uwe Kleine-König]

On Thu, Jun 03, 2010 at 09:55:19PM +0200, Marek Vasut wrote:
> Dne ?t 3. ?ervna 2010 21:24:59 Russell King - ARM Linux napsal(a):
> > The subject says everything you need to know.  Randy provided this
> > link earlier:
> > 
> >   http://lkml.org/lkml/2010/6/2/472
> > 
> > Linus doesn't appear to be listening to reason, so I see now this as
> > a fait accompli.  It'll apparantly happen at the next merge window.
> 
> The defconfigs age ... there's no point keeping them. They'll be useless crap 
> unless someone updates them often anyway.
Some time ago I wrote a little script that minimized a .config and
applied it to ns9xxx_defconfig.

The result is that ns9xxx_defconfig only has 79 lines while the average
is >1200.  (I have to admit that ns9xxx isn't complete by far as there
are no device drivers in tree, but anyhow, after $(make
ns9xxx_defconfig) the resulting .config has 1181 lines.) Would it already
help to apply it to all defconfigs?  A nice effect is that changes to
these small files are smaller and so easier to understand.  IIRC I posted
the script to linux-kbuild back then.  I can try to find and apply it
before the next merge window.

And I want to point out that there are efforts to merge all arch-mx* and
plat-mxc and so reduce the number of defconfigs from seven[1] to one.
Eric picked up on the runtime-physoffset patches that are currently a
stopper for (AFAIK) several merges.

Best regards
Uwe

[1] IIRC I recently saw a patch that adds mx25_defconfig, so there are
even eight imx defconfigs.

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Thu, 3 Jun 2010, Russell King - ARM Linux wrote:

> The subject says everything you need to know.  Randy provided this
> link earlier:
> 
>   http://lkml.org/lkml/2010/6/2/472

Leaving the drama aside...

I agree that there is indeed a growing problem with the growing number 
of ever growing defconfigs.

And the problem is made even worse by the diversity, and shall we say 
"success" of the ARM architecture.

The average defconfig file for a new target is going to be _larger_ than 
the size of the actual source code for that target if the trend 
continues.

Let's acknowledge the problem and try to come up with a solution.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Thu, Jun 03, 2010 at 03:59:03PM -0400, Nicolas Pitre wrote:
> On Thu, 3 Jun 2010, Russell King - ARM Linux wrote:
> 
> > The subject says everything you need to know.  Randy provided this
> > link earlier:
> > 
> >   http://lkml.org/lkml/2010/6/2/472
> 
> Leaving the drama aside...

Err, what drama?  Don't you think it would be absolutely stupid of me
_not_ to highlight what's going to happen?  I'm sure there would also
be complaints if I didn't bring people's attention to it.

Damned if I do, and damned if I don't.  So I can't win.

> Let's acknowledge the problem and try to come up with a solution.

I agree with you, but it has already proven pointless to discuss.

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Thu, 3 Jun 2010, Russell King - ARM Linux wrote:

> On Thu, Jun 03, 2010 at 03:59:03PM -0400, Nicolas Pitre wrote:
> > On Thu, 3 Jun 2010, Russell King - ARM Linux wrote:
> > 
> > > The subject says everything you need to know.  Randy provided this
> > > link earlier:
> > > 
> > >   http://lkml.org/lkml/2010/6/2/472
> > 
> > Leaving the drama aside...
> 
> Err, what drama?  Don't you think it would be absolutely stupid of me
> _not_ to highlight what's going to happen?

That's part of the drama.  And Linus is also playing a lead role in it.

Let's just try to step back and find a rational solution.

> > Let's acknowledge the problem and try to come up with a solution.
> 
> I agree with you, but it has already proven pointless to discuss.

I won't give up just yet.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Russell King - ARM Linux wrote:
> The subject says everything you need to know.  Randy provided this
> link earlier:
> 
>   http://lkml.org/lkml/2010/6/2/472
> 
> Linus doesn't appear to be listening to reason, so I see now this as
> a fait accompli.  It'll apparantly happen at the next merge window.
> 
> So, don't send anything which contains a defconfig file or updates to
> it.  It's pointless.

Is it worth being a bit proactive and getting rid of some of them in
advance? Things like spear3[012]0_defconfig are basically identically
except for the board type. Combining all three of those would remove
1500 lines of code.

Basically reduce down to one or two defconfigs for each mach directory
which include as many boards and drivers as possible. People wanting
more tailored configs can do that in their own trees.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Fri, 4 Jun 2010, Ryan Mallon wrote:

> Is it worth being a bit proactive and getting rid of some of them in
> advance? Things like spear3[012]0_defconfig are basically identically
> except for the board type. Combining all three of those would remove
> 1500 lines of code.

Please go ahead with a patch.

> Basically reduce down to one or two defconfigs for each mach directory
> which include as many boards and drivers as possible. People wanting
> more tailored configs can do that in their own trees.

This actually should have been the plan from the start.  See for example 
orion5x_defconfig which currently already supports 23 machines.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Nicolas Pitre wrote:
> On Fri, 4 Jun 2010, Ryan Mallon wrote:
> 
>> Is it worth being a bit proactive and getting rid of some of them in
>> advance? Things like spear3[012]0_defconfig are basically identically
>> except for the board type. Combining all three of those would remove
>> 1500 lines of code.
> 
> Please go ahead with a patch.

Hmm, not as easy as I thought. The three boards cannot be built into a
single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
extern a bunch of structs which have naming conflicts.

It does look possible to rewrite that code so that all three boards can
be built into a single kernel. I can try and put together a patch, but I
don't have any hardware to test with.

The at91 is actually in a similar state, where only one of the
at91sam9260, at91sam9g45, etc can be selected. Again, it should be
possible to rework the code so that most of the different cpus can be
built into a single kernel. I'm sure other mach's are in a simliar
state. Fixing these where possible would allow us to have single
defconfigs per mach directory and reduce code churn, which is what Linus
is really complaining about.

>> Basically reduce down to one or two defconfigs for each mach directory
>> which include as many boards and drivers as possible. People wanting
>> more tailored configs can do that in their own trees.
> 
> This actually should have been the plan from the start.  See for example 
> orion5x_defconfig which currently already supports 23 machines.

It seems that in a few cases at least the problem is really that all of
the boards for a mach directory cannot be compiled into one kernel.
Fixing that would be a useful goal.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Kyungmin Park]

On Fri, Jun 4, 2010 at 8:33 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> Nicolas Pitre wrote:
>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
>>
>>> Is it worth being a bit proactive and getting rid of some of them in
>>> advance? Things like spear3[012]0_defconfig are basically identically
>>> except for the board type. Combining all three of those would remove
>>> 1500 lines of code.
>>
>> Please go ahead with a patch.
>
> Hmm, not as easy as I thought. The three boards cannot be built into a
> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
> extern a bunch of structs which have naming conflicts.
>
> It does look possible to rewrite that code so that all three boards can
> be built into a single kernel. I can try and put together a patch, but I
> don't have any hardware to test with.
>
> The at91 is actually in a similar state, where only one of the
> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
> possible to rework the code so that most of the different cpus can be
> built into a single kernel. I'm sure other mach's are in a simliar
> state. Fixing these where possible would allow us to have single
> defconfigs per mach directory and reduce code churn, which is what Linus
> is really complaining about.
>
>>> Basically reduce down to one or two defconfigs for each mach directory
>>> which include as many boards and drivers as possible. People wanting
>>> more tailored configs can do that in their own trees.
>>
>> This actually should have been the plan from the start. ?See for example
>> orion5x_defconfig which currently already supports 23 machines.

If target has several variants with different memory size, different
GPIOs. It's really hard to maintain and support.
To address this issues. we implement the detect routine and give
different system revision at bootloader side and kernel boot with this
information. with this approaches I can support 5 different targets
based on s5pc110.

In previous time, we usually make a kernel for each boards but it's
hard works and takes long time. So single kernel is best approaches
and it's possible at least similar CPUs. e.g. samsung s5p series.

As I know s5pc110 (aka s5pv210) and s5p644x is similar and can
possible to make single kernel.

Thank you,
Kyungmin Park

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Fri, 4 Jun 2010, Kyungmin Park wrote:

> If target has several variants with different memory size, different
> GPIOs. It's really hard to maintain and support.
> To address this issues. we implement the detect routine and give
> different system revision at bootloader side and kernel boot with this
> information. with this approaches I can support 5 different targets
> based on s5pc110.

Please have a look at arch/arm/mach-kirkwood/netspace_v2-setup.c for 
example.  This file contains the support for two boards already.  
They're supported by the same source files because they have lot of code 
in common.  but the differences are distinguished by the machine ID 
number passed into r1 by the bootloader used to select which machine 
record is selected.  The proper machine_init method within each of those 
machine records is called on boot, where a different table for GPIO 
initialization (it is called MPP on Kirkwood) is again selected.  All 
this is accomplished at run time.

If you want more complex GPIO config variants, have a look at mach-pxa/* 
where they're called MFP instead.

Memory size should normally be detected and passed along to the kernel 
by the bootloader.

> In previous time, we usually make a kernel for each boards but it's
> hard works and takes long time. So single kernel is best approaches
> and it's possible at least similar CPUs. e.g. samsung s5p series.
> 
> As I know s5pc110 (aka s5pv210) and s5p644x is similar and can
> possible to make single kernel.

Exact.  It is always a good idea to try to compile as many boards as 
possible in a single kernel, and then have the ability to optimize the 
kernel configuration in order to have the support for only one board 
built into the kernel if desired.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
> Nicolas Pitre wrote:
> > On Fri, 4 Jun 2010, Ryan Mallon wrote:
> >> Is it worth being a bit proactive and getting rid of some of them in
> >> advance? Things like spear3[012]0_defconfig are basically identically
> >> except for the board type. Combining all three of those would remove
> >> 1500 lines of code.
> > 
> > Please go ahead with a patch.
> 
> Hmm, not as easy as I thought. The three boards cannot be built into a
> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
> extern a bunch of structs which have naming conflicts.
> 
> It does look possible to rewrite that code so that all three boards can
> be built into a single kernel. I can try and put together a patch, but I
> don't have any hardware to test with.
> 
> The at91 is actually in a similar state, where only one of the
> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
> possible to rework the code so that most of the different cpus can be
> built into a single kernel. I'm sure other mach's are in a simliar
> state. Fixing these where possible would allow us to have single
> defconfigs per mach directory and reduce code churn, which is what Linus
> is really complaining about.

I just tested, PXA (mach-pxa) probably can be compiled into single kernel 
supporting all the boards.

> 
> >> Basically reduce down to one or two defconfigs for each mach directory
> >> which include as many boards and drivers as possible. People wanting
> >> more tailored configs can do that in their own trees.
> > 
> > This actually should have been the plan from the start.  See for example
> > orion5x_defconfig which currently already supports 23 machines.
> 
> It seems that in a few cases at least the problem is really that all of
> the boards for a mach directory cannot be compiled into one kernel.
> Fixing that would be a useful goal.
> 
> ~Ryan

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Marek Vasut wrote:
> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
>> Nicolas Pitre wrote:
>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
>>>> Is it worth being a bit proactive and getting rid of some of them in
>>>> advance? Things like spear3[012]0_defconfig are basically identically
>>>> except for the board type. Combining all three of those would remove
>>>> 1500 lines of code.
>>> Please go ahead with a patch.
>> Hmm, not as easy as I thought. The three boards cannot be built into a
>> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
>> extern a bunch of structs which have naming conflicts.
>>
>> It does look possible to rewrite that code so that all three boards can
>> be built into a single kernel. I can try and put together a patch, but I
>> don't have any hardware to test with.
>>
>> The at91 is actually in a similar state, where only one of the
>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
>> possible to rework the code so that most of the different cpus can be
>> built into a single kernel. I'm sure other mach's are in a simliar
>> state. Fixing these where possible would allow us to have single
>> defconfigs per mach directory and reduce code churn, which is what Linus
>> is really complaining about.
> 
> I just tested, PXA (mach-pxa) probably can be compiled into single kernel 
> supporting all the boards.

Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
that state.

ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
25

Can we remove/combine some of those?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Fri, Jun 4, 2010 at 9:16 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> Marek Vasut wrote:
>> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
>>> Nicolas Pitre wrote:
>>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
>>>>> Is it worth being a bit proactive and getting rid of some of them in
>>>>> advance? Things like spear3[012]0_defconfig are basically identically
>>>>> except for the board type. Combining all three of those would remove
>>>>> 1500 lines of code.
>>>> Please go ahead with a patch.
>>> Hmm, not as easy as I thought. The three boards cannot be built into a
>>> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
>>> extern a bunch of structs which have naming conflicts.
>>>
>>> It does look possible to rewrite that code so that all three boards can
>>> be built into a single kernel. I can try and put together a patch, but I
>>> don't have any hardware to test with.
>>>
>>> The at91 is actually in a similar state, where only one of the
>>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
>>> possible to rework the code so that most of the different cpus can be
>>> built into a single kernel. I'm sure other mach's are in a simliar
>>> state. Fixing these where possible would allow us to have single
>>> defconfigs per mach directory and reduce code churn, which is what Linus
>>> is really complaining about.
>>
>> I just tested, PXA (mach-pxa) probably can be compiled into single kernel
>> supporting all the boards.
>
> Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
> that state.
>
> ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
> 25
>
> Can we remove/combine some of those?
>

Definitely. In the end of the day, I would like to see pxa_defconfig only.
But at the moment, I need every board maintainer to review their defconfig
and combine them as much as possible. E.g.

palmte_defconfig   palmtt_defconfig   palmz71_defconfig  palmz72_defconfig

I'd guess can simply combine into one. (Marek, feel free to do it)

I'd more like a step to step work instead of a brutely removal of all defconfig,
not sure if Linus is going to buy in.

For those sub-arch which cannot simply compile a single kernel for multiple
boards, s5p* as previously mentioned, I suggest not to introduce any new
defconfig until the problem is solved.

Also, we are now working on a single kernel for multiple sub-arch (at least
what Nicolas and I am doing now, and welcome to join us). It's tough (the
way to handle different phys_offset is only the tip of the iceberg) and seems
now more and more necessary. so hopefully by the end of the day, we may
possible end up with only very few defconfig.

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne P? 4. ?ervna 2010 03:35:28 Eric Miao napsal(a):
> On Fri, Jun 4, 2010 at 9:16 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> > Marek Vasut wrote:
> >> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
> >>> Nicolas Pitre wrote:
> >>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
> >>>>> Is it worth being a bit proactive and getting rid of some of them in
> >>>>> advance? Things like spear3[012]0_defconfig are basically identically
> >>>>> except for the board type. Combining all three of those would remove
> >>>>> 1500 lines of code.
> >>>> 
> >>>> Please go ahead with a patch.
> >>> 
> >>> Hmm, not as easy as I thought. The three boards cannot be built into a
> >>> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
> >>> extern a bunch of structs which have naming conflicts.
> >>> 
> >>> It does look possible to rewrite that code so that all three boards can
> >>> be built into a single kernel. I can try and put together a patch, but
> >>> I don't have any hardware to test with.
> >>> 
> >>> The at91 is actually in a similar state, where only one of the
> >>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
> >>> possible to rework the code so that most of the different cpus can be
> >>> built into a single kernel. I'm sure other mach's are in a simliar
> >>> state. Fixing these where possible would allow us to have single
> >>> defconfigs per mach directory and reduce code churn, which is what
> >>> Linus is really complaining about.
> >> 
> >> I just tested, PXA (mach-pxa) probably can be compiled into single
> >> kernel supporting all the boards.
> > 
> > Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
> > that state.
> > 
> > ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
> > 25
> > 
> > Can we remove/combine some of those?
> 
> Definitely. In the end of the day, I would like to see pxa_defconfig only.
> But at the moment, I need every board maintainer to review their defconfig
> and combine them as much as possible. E.g.
> 
> palmte_defconfig   palmtt_defconfig   palmz71_defconfig  palmz72_defconfig

This is OMAP stuff, not PXA. But yeah, these could be combined. I don't have 
these devices available at the moment (and it might be a problem getting them 
into operational state).
> 
> I'd guess can simply combine into one. (Marek, feel free to do it)
> 
> I'd more like a step to step work instead of a brutely removal of all
> defconfig, not sure if Linus is going to buy in.
> 
> For those sub-arch which cannot simply compile a single kernel for multiple
> boards, s5p* as previously mentioned, I suggest not to introduce any new
> defconfig until the problem is solved.
> 
> Also, we are now working on a single kernel for multiple sub-arch (at least
> what Nicolas and I am doing now, and welcome to join us). It's tough (the
> way to handle different phys_offset is only the tip of the iceberg) and
> seems now more and more necessary. so hopefully by the end of the day, we
> may possible end up with only very few defconfig.

How long is your day now ?

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne P? 4. ?ervna 2010 03:37:10 Marek Vasut napsal(a):
> Dne P? 4. ?ervna 2010 03:35:28 Eric Miao napsal(a):
> > On Fri, Jun 4, 2010 at 9:16 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> > > Marek Vasut wrote:
> > >> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
> > >>> Nicolas Pitre wrote:
> > >>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
> > >>>>> Is it worth being a bit proactive and getting rid of some of them
> > >>>>> in advance? Things like spear3[012]0_defconfig are basically
> > >>>>> identically except for the board type. Combining all three of
> > >>>>> those would remove 1500 lines of code.
> > >>>> 
> > >>>> Please go ahead with a patch.
> > >>> 
> > >>> Hmm, not as easy as I thought. The three boards cannot be built into
> > >>> a single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c
> > >>> files all extern a bunch of structs which have naming conflicts.
> > >>> 
> > >>> It does look possible to rewrite that code so that all three boards
> > >>> can be built into a single kernel. I can try and put together a
> > >>> patch, but I don't have any hardware to test with.
> > >>> 
> > >>> The at91 is actually in a similar state, where only one of the
> > >>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
> > >>> possible to rework the code so that most of the different cpus can be
> > >>> built into a single kernel. I'm sure other mach's are in a simliar
> > >>> state. Fixing these where possible would allow us to have single
> > >>> defconfigs per mach directory and reduce code churn, which is what
> > >>> Linus is really complaining about.
> > >> 
> > >> I just tested, PXA (mach-pxa) probably can be compiled into single
> > >> kernel supporting all the boards.
> > > 
> > > Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
> > > that state.
> > > 
> > > ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
> > > 25
> > > 
> > > Can we remove/combine some of those?
> > 
> > Definitely. In the end of the day, I would like to see pxa_defconfig
> > only. But at the moment, I need every board maintainer to review their
> > defconfig and combine them as much as possible. E.g.
> > 
> > palmte_defconfig   palmtt_defconfig   palmz71_defconfig 
> > palmz72_defconfig
> 

OMAP: palmte_defconfig, palmtt_defconfig, palmz71_defconfig
PXA: palmz72_defconfig ... the rest of palmxx_defconfig

Sorry about the confusion

> This is OMAP stuff, not PXA. But yeah, these could be combined. I don't
> have these devices available at the moment (and it might be a problem
> getting them into operational state).
> 
> > I'd guess can simply combine into one. (Marek, feel free to do it)
> > 
> > I'd more like a step to step work instead of a brutely removal of all
> > defconfig, not sure if Linus is going to buy in.
> > 
> > For those sub-arch which cannot simply compile a single kernel for
> > multiple boards, s5p* as previously mentioned, I suggest not to
> > introduce any new defconfig until the problem is solved.
> > 
> > Also, we are now working on a single kernel for multiple sub-arch (at
> > least what Nicolas and I am doing now, and welcome to join us). It's
> > tough (the way to handle different phys_offset is only the tip of the
> > iceberg) and seems now more and more necessary. so hopefully by the end
> > of the day, we may possible end up with only very few defconfig.
> 
> How long is your day now ?

Heads up: Linus plans to kill ARM defconfigs

[Marek Vasut]

Dne P? 4. ?ervna 2010 03:50:36 Marek Vasut napsal(a):
> Dne P? 4. ?ervna 2010 03:37:10 Marek Vasut napsal(a):
> > Dne P? 4. ?ervna 2010 03:35:28 Eric Miao napsal(a):
> > > On Fri, Jun 4, 2010 at 9:16 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
> > > > Marek Vasut wrote:
> > > >> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
> > > >>> Nicolas Pitre wrote:
> > > >>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
> > > >>>>> Is it worth being a bit proactive and getting rid of some of them
> > > >>>>> in advance? Things like spear3[012]0_defconfig are basically
> > > >>>>> identically except for the board type. Combining all three of
> > > >>>>> those would remove 1500 lines of code.
> > > >>>> 
> > > >>>> Please go ahead with a patch.
> > > >>> 
> > > >>> Hmm, not as easy as I thought. The three boards cannot be built
> > > >>> into a single kernel since the
> > > >>> arch/arm/mach-spear3xx/spear3[012]0.c files all extern a bunch of
> > > >>> structs which have naming conflicts.
> > > >>> 
> > > >>> It does look possible to rewrite that code so that all three boards
> > > >>> can be built into a single kernel. I can try and put together a
> > > >>> patch, but I don't have any hardware to test with.
> > > >>> 
> > > >>> The at91 is actually in a similar state, where only one of the
> > > >>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
> > > >>> possible to rework the code so that most of the different cpus can
> > > >>> be built into a single kernel. I'm sure other mach's are in a
> > > >>> simliar state. Fixing these where possible would allow us to have
> > > >>> single defconfigs per mach directory and reduce code churn, which
> > > >>> is what Linus is really complaining about.
> > > >> 
> > > >> I just tested, PXA (mach-pxa) probably can be compiled into single
> > > >> kernel supporting all the boards.
> > > > 
> > > > Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
> > > > that state.
> > > > 
> > > > ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
> > > > 25
> > > > 
> > > > Can we remove/combine some of those?
> > > 
> > > Definitely. In the end of the day, I would like to see pxa_defconfig
> > > only. But at the moment, I need every board maintainer to review their
> > > defconfig and combine them as much as possible. E.g.
> > > 
> > > palmte_defconfig   palmtt_defconfig   palmz71_defconfig
> > > palmz72_defconfig
> 
> OMAP: palmte_defconfig, palmtt_defconfig, palmz71_defconfig

Ok, making them into one is compile tested. I'd be for calling it a 
"palmomap_defconfig". Or maybe is there a plan to put whole OMAP1 into a single 
defconfig ?

> PXA: palmz72_defconfig ... the rest of palmxx_defconfig
> 
> Sorry about the confusion
> 
> > This is OMAP stuff, not PXA. But yeah, these could be combined. I don't
> > have these devices available at the moment (and it might be a problem
> > getting them into operational state).
> > 
> > > I'd guess can simply combine into one. (Marek, feel free to do it)
> > > 
> > > I'd more like a step to step work instead of a brutely removal of all
> > > defconfig, not sure if Linus is going to buy in.
> > > 
> > > For those sub-arch which cannot simply compile a single kernel for
> > > multiple boards, s5p* as previously mentioned, I suggest not to
> > > introduce any new defconfig until the problem is solved.
> > > 
> > > Also, we are now working on a single kernel for multiple sub-arch (at
> > > least what Nicolas and I am doing now, and welcome to join us). It's
> > > tough (the way to handle different phys_offset is only the tip of the
> > > iceberg) and seems now more and more necessary. so hopefully by the end
> > > of the day, we may possible end up with only very few defconfig.
> > 
> > How long is your day now ?

Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Marek Vasut <marek.vasut@gmail.com> [100604 04:54]:
> > 
> > OMAP: palmte_defconfig, palmtt_defconfig, palmz71_defconfig
> 
> Ok, making them into one is compile tested. I'd be for calling it a 
> "palmomap_defconfig". Or maybe is there a plan to put whole OMAP1 into a single 
> defconfig ?

Yeah, we should have just one omap1_defconfig. It should already
mostly work already for 15xx + 16xx. To build in 7xx, the entry-macro.S
needs to be done the same way as for mach-omap2.

Regards,

Tony

Heads up: Linus plans to kill ARM defconfigs

[Cory Maccarrone]

Tony Lindgren <tony <at> atomide.com> writes:

> 
> 
> Yeah, we should have just one omap1_defconfig. It should already
> mostly work already for 15xx + 16xx. To build in 7xx, the entry-macro.S
> needs to be done the same way as for mach-omap2.
> 
> Regards,
> 
> Tony
> 

All the new omap7xx boards I plan to submit in the future should be able to work
fine in a single defconfig.  That's how I build now with my development tree.
I'd be perfectly happy to see my htcherald_defconfig get wrapped into a more
generic omap1_defconfig.

They might even be generic enough that I won't need separate board files for
them -- I'll have to see when I get to that point.

- Cory

Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Cory Maccarrone <darkstar6262@gmail.com> [100604 18:05]:
> Tony Lindgren <tony <at> atomide.com> writes:
> 
> All the new omap7xx boards I plan to submit in the future should be able to work
> fine in a single defconfig.  That's how I build now with my development tree.
> I'd be perfectly happy to see my htcherald_defconfig get wrapped into a more
> generic omap1_defconfig.

OK. Do you want to take a look at fixing the omap1 entry-macro.S in a similar
way to omap2 entry-macro.S so it works on 7xx too? See the ifdef MULTI_OMAP2
in entry-macro.S. 15xx is ARM925 based, so that's easy to detect. But for
detecting between ARM926 based 7xx and 16xx you would have to use some other
register.
 
> They might even be generic enough that I won't need separate board files for
> them -- I'll have to see when I get to that point.

OK

Regards,

Tony

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Fri, Jun 4, 2010 at 9:37 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Dne P? 4. ?ervna 2010 03:35:28 Eric Miao napsal(a):
>> On Fri, Jun 4, 2010 at 9:16 AM, Ryan Mallon <ryan@bluewatersys.com> wrote:
>> > Marek Vasut wrote:
>> >> Dne P? 4. ?ervna 2010 01:33:35 Ryan Mallon napsal(a):
>> >>> Nicolas Pitre wrote:
>> >>>> On Fri, 4 Jun 2010, Ryan Mallon wrote:
>> >>>>> Is it worth being a bit proactive and getting rid of some of them in
>> >>>>> advance? Things like spear3[012]0_defconfig are basically identically
>> >>>>> except for the board type. Combining all three of those would remove
>> >>>>> 1500 lines of code.
>> >>>>
>> >>>> Please go ahead with a patch.
>> >>>
>> >>> Hmm, not as easy as I thought. The three boards cannot be built into a
>> >>> single kernel since the arch/arm/mach-spear3xx/spear3[012]0.c files all
>> >>> extern a bunch of structs which have naming conflicts.
>> >>>
>> >>> It does look possible to rewrite that code so that all three boards can
>> >>> be built into a single kernel. I can try and put together a patch, but
>> >>> I don't have any hardware to test with.
>> >>>
>> >>> The at91 is actually in a similar state, where only one of the
>> >>> at91sam9260, at91sam9g45, etc can be selected. Again, it should be
>> >>> possible to rework the code so that most of the different cpus can be
>> >>> built into a single kernel. I'm sure other mach's are in a simliar
>> >>> state. Fixing these where possible would allow us to have single
>> >>> defconfigs per mach directory and reduce code churn, which is what
>> >>> Linus is really complaining about.
>> >>
>> >> I just tested, PXA (mach-pxa) probably can be compiled into single
>> >> kernel supporting all the boards.
>> >
>> > Yes, IIRC Russell and Eric did a huge amount of work to get pxa into
>> > that state.
>> >
>> > ryan at okiwi:configs$ grep "ARCH_PXA=y" * | wc -l
>> > 25
>> >
>> > Can we remove/combine some of those?
>>
>> Definitely. In the end of the day, I would like to see pxa_defconfig only.
>> But at the moment, I need every board maintainer to review their defconfig
>> and combine them as much as possible. E.g.
>>
>> palmte_defconfig ? palmtt_defconfig ? palmz71_defconfig ?palmz72_defconfig
>
> This is OMAP stuff, not PXA. But yeah, these could be combined. I don't have
> these devices available at the moment (and it might be a problem getting them
> into operational state).
>>
>> I'd guess can simply combine into one. (Marek, feel free to do it)
>>
>> I'd more like a step to step work instead of a brutely removal of all
>> defconfig, not sure if Linus is going to buy in.
>>
>> For those sub-arch which cannot simply compile a single kernel for multiple
>> boards, s5p* as previously mentioned, I suggest not to introduce any new
>> defconfig until the problem is solved.
>>
>> Also, we are now working on a single kernel for multiple sub-arch (at least
>> what Nicolas and I am doing now, and welcome to join us). It's tough (the
>> way to handle different phys_offset is only the tip of the iceberg) and
>> seems now more and more necessary. so hopefully by the end of the day, we
>> may possible end up with only very few defconfig.
>
> How long is your day now ?
>

In the end of the day, sorry, it's a very long. You know English is not my
tongue ;-)

Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Eric Miao <eric.y.miao@gmail.com> [100604 04:35]:
> 
> Also, we are now working on a single kernel for multiple sub-arch (at least
> what Nicolas and I am doing now, and welcome to join us). It's tough (the
> way to handle different phys_offset is only the tip of the iceberg) and seems
> now more and more necessary. so hopefully by the end of the day, we may
> possible end up with only very few defconfig.

Great, do you have some git branch for that somewhere?

Parallel to dealing with different phys_offset we can also try combining
some two ARM platforms that have the same phy_offset. That already exposes
tons of conflicting defines that need to be sorted out..

Regards,

Tony

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Fri, Jun 4, 2010 at 2:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Eric Miao <eric.y.miao@gmail.com> [100604 04:35]:
>>
>> Also, we are now working on a single kernel for multiple sub-arch (at least
>> what Nicolas and I am doing now, and welcome to join us). It's tough (the
>> way to handle different phys_offset is only the tip of the iceberg) and seems
>> now more and more necessary. so hopefully by the end of the day, we may
>> possible end up with only very few defconfig.
>
> Great, do you have some git branch for that somewhere?
>

All the currently done work I've posted to the mailing list:

1. SPARSEIRQ
2. MULTI_IRQ_HANDLER
3. Makefile.boot move to arch/arm/boot/bootp _only_
4. RUNTIME_PHYS_OFFSET (not really my work, but Uwe's)

Nico and I have setup a blueprint and wiki spec for this, I hope more
can join us with the effort.

https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage
https://wiki.ubuntu.com/Specs/ARMSingleKernel

I'll push what I did to

git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
unified-kernel

But it's a mess now.

> Parallel to dealing with different phys_offset we can also try combining
> some two ARM platforms that have the same phy_offset. That already exposes
> tons of conflicting defines that need to be sorted out..
>

A first step to take might be looking at all those machine specific header
files that will be included into generic <asm/*.h> and in turn included by
other code. The PHYS_OFFSET is only a small tip of the iceberg I'm afraid.
A very rough grep and analysis as below:

`    $ git grep "#include <mach" arch/arm/include/asm/` <<BR>>
`    arch/arm/include/asm/dma.h:#include <mach/isa-dma.h>` <<BR>>
`    arch/arm/include/asm/floppy.h:#include <mach/floppy.h>` <<BR>>
`    arch/arm/include/asm/gpio.h:#include <mach/gpio.h>` <<BR>>
`    arch/arm/include/asm/hardware/dec21285.h:#include <mach/hardware.h>` <<BR>>
`    arch/arm/include/asm/hardware/iop3xx-adma.h:#include
<mach/hardware.h>` <<BR>>
`    arch/arm/include/asm/hardware/iop3xx-gpio.h:#include
<mach/hardware.h>` <<BR>>
`    arch/arm/include/asm/hardware/sa1111.h:#include <mach/bitfield.h>` <<BR>>
`    arch/arm/include/asm/io.h:#include <mach/io.h>` <<BR>>
`    arch/arm/include/asm/irq.h:#include <mach/irqs.h>` <<BR>>
`    arch/arm/include/asm/mc146818rtc.h:#include <mach/irqs.h>` <<BR>>
`    arch/arm/include/asm/memory.h:#include <mach/memory.h>` <<BR>>
`    arch/arm/include/asm/mmzone.h:#include <mach/memory.h>` <<BR>>
`    arch/arm/include/asm/mtd-xip.h:#include <mach/mtd-xip.h>` <<BR>>
`    arch/arm/include/asm/pci.h:#include <mach/hardware.h> /* for
PCIBIOS_MIN_* */` <<BR>>
`    arch/arm/include/asm/pgtable.h:#include <mach/vmalloc.h>` <<BR>>
`    arch/arm/include/asm/smp.h:#include <mach/smp.h>` <<BR>>
`    arch/arm/include/asm/system.h:#include <mach/barriers.h>` <<BR>>
`    arch/arm/include/asm/timex.h:#include <mach/timex.h>` <<BR>>
`    arch/arm/include/asm/vga.h:#include <mach/hardware.h>` <<BR>>

  * <mach/floppy.h> is no longer necessary

1.  arch/arm/include/asm/memory.h:#include <mach/memory.h>

1.1 PHYS_OFFSET

  * can be ignored if RUNTIME_PHYS_OFFSET is doable
  * should be removed from <mach/memory.h>
  * but we need this somewhere to allow the usage of a hardcoded constant
    [a config option?]

1.2 ISA_DMA_THRESHOLD and DMA_MAX_ADDRESS

  * make them into variables and encode them in machine_desc

1.3 arch_adjust_zones()

  * can be moved into machine_desc
  * this depends on CONFIG_ZONE_DMA
  * what to do with CONFIG_ZONE_DMA?

1.4 NODE_MEM_SIZE_BITS, SECTION_SIZE_BITS, MAX_PHYSMEM_BITS, ...

1.5 CONFIG_SPARSEMEM

  * N/A

2. arch/arm/include/asm/dma.h:#include <mach/isa-dma.h>

  * depends on CONFIG_ISA_DMA_API
  * currently only the machines below:
    * arch/arm/mach-h720x/include/mach/isa-dma.h
    * arch/arm/mach-footbridge/include/mach/isa-dma.h
    * arch/arm/mach-shark/include/mach/isa-dma.h
    * arch/arm/mach-rpc/include/mach/isa-dma.h
  * the most important definition is MAX_DMA_CHANNELS, which can be
    converted to a variable
  * some other machine specific definitions

3. arch/arm/include/asm/gpio.h:#include <mach/gpio.h>

  * gpio_to_irq() and irq_to_gpio(), need to make this generic but
    could hurt performance
  * inlined version of gpio_{get,set}_value(), gpio_direction_*()
    and others will conflict with each other
  * some other definitions like GPIO registers

4. arch/arm/include/asm/hardware/dec21285.h:#include <mach/hardware.h>
   arch/arm/include/asm/hardware/iop3xx-adma.h:#include <mach/hardware.h>
   arch/arm/include/asm/hardware/iop3xx-gpio.h:#include <mach/hardware.h>
   arch/arm/include/asm/vga.h:#include <mach/hardware.h>

  * <mach/hardware.h> is really machine specific and could possibly contain
    anything

5. arch/arm/include/asm/io.h:#include <mach/io.h>

  * IO_SPACE_LIMIT (actually IO_SPACE_LIMIT for _all_ machines are now
    0xffff_ffff), if no exception could just be removed and make it a
    default
  * definitions of __io(), this is defined as __typesafe_io(a) on most
    platforms, on other platforms, it can be abstracted as
`      ((void __iomem *)(BASE + (a)))` <<BR>>
    as long as we can make BASE a variable, this can be removed
  * definitions of __mem_pci(a), defined as (a) on all platforms, can
    be removed and make a default
  * ixp4xx is especially complex, depending on INDIRECT_PCI and PCI
  * how to handle different definitions of {in,out}{b,w,l}()
  * __arch_ioremap() and __arch_iounmap()

6. arch/arm/include/asm/irq.h:#include <mach/irqs.h>

  * what <asm/irq.h> needs is NR_IRQS (can be solved by SPARSEIRQ)
  * <mach/irqs.h> can be made internal to machine specific code _only_

7. arch/arm/include/asm/mtd-xip.h:#include <mach/mtd-xip.h>

  * currently, only omap1, pxa, sa1100 supports this
  * xip_irqpending()
  * xip_currtime()
  * xip_elapsed_since()
  * xip_cpu_idle()

8. arch/arm/include/asm/pci.h:#include <mach/hardware.h> /* for PCIBIOS_MIN_* */

  * need to make PCIBIOS_MIN_* variables

9. arch/arm/include/asm/pgtable.h:#include <mach/vmalloc.h>

  * mainly for VMALLOC_END could be made into a machine specific variable

10. arch/arm/include/asm/smp.h:#include <mach/smp.h>

  * smp_cross_call()
  * hard_smp_processor_id()

11. arch/arm/include/asm/system.h:#include <mach/barriers.h>

  * currently no machine defines barriers.h

12. arch/arm/include/asm/timex.h:#include <mach/timex.h>

  * CLOCK_TICK_RATE, can actually be removed

Heads up: Linus plans to kill ARM defconfigs

[Martin Guy]

I think you've missed the point.

Linus' problem is that he is spending MOST of his linux-kernel-support
time fielding patches from a dozen port maintainers, and dropping
defconfigs is a desperate attempt to cut the amount of arm fiddling he
is asked to do, and I guess droppiong defconfigs seems to him to be
they way to cut the least important and most verbose part of this
drudgery.
I'm sure he'd rather be writing programs.

While a defconfig restructuring does address the specific issue it's
pointless. He's going to drop defconfigs, so we'll all just have to
have our own web pages giving our suggested defconfigs for our own
boards.

Shame. I was about to post a Sim.One defconfig patch (while fully
realizing that the choice of options is largely arbitrary. and copied
ad-hoc from some other similar defconfig). While it's nice to be able
to tell people "make foobar_defconfig; make (z|u|bz)Image" in reality
the config is as arbitrary as the root filesystem in use (and should
be chosen to match it).

The best way to free up many hours every day of Linus' time is for one
person to isolate him from the port maintainers, so that he only has
to pull (ideally) once per release cycle from one repository.

The question is, do we have the resources and the organization to take
that constant burden of work off one of our brightest programmers so
that he can get on with what he's really interested in?

    M

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Fri, 4 Jun 2010, Martin Guy wrote:

> I think you've missed the point.
> 
> Linus' problem is that he is spending MOST of his linux-kernel-support
> time fielding patches from a dozen port maintainers, and dropping
> defconfigs is a desperate attempt to cut the amount of arm fiddling he
> is asked to do, and I guess droppiong defconfigs seems to him to be
> they way to cut the least important and most verbose part of this
> drudgery.

Not exactly.  If you read along the thread, you'll see that what Linus 
is actually complaining about is the fact that those defconfig files are 
huge and clutter the source tree for little value.  When someone sends 
him a pull request for some ARM target, the actual diffstat/dirstat is 
dominated by the defconfig file changes, making the review exercise 
futile (even if Linus is probably merely only looking at the diffstat 
for ARM merges).

> While a defconfig restructuring does address the specific issue it's
> pointless. He's going to drop defconfigs, so we'll all just have to
> have our own web pages giving our suggested defconfigs for our own
> boards.

Linus wants something to be done about the current defconfig mess which 
is perfectly legitimate.  He even suggested a possible solution.  I 
don't think he'll simply drop those defconfig files if we demonstrate 
that we're taking action to fix the actual problem.

In the mean time, anything that can be done today to reduce the number 
of defconfig files is a good thing.  In some cases we're even talking 
about merging 7 of those into 1.  Those are low hanging fruits that are 
absolutely worth the little effort required, and that would help with 
kernel compilation tests.

> Shame. I was about to post a Sim.One defconfig patch (while fully
> realizing that the choice of options is largely arbitrary. and copied
> ad-hoc from some other similar defconfig). While it's nice to be able
> to tell people "make foobar_defconfig; make (z|u|bz)Image" in reality
> the config is as arbitrary as the root filesystem in use (and should
> be chosen to match it).

Sure.  All the defconfigs are largely arbitrary.  What needs to be done, 
though, is some way to preserve the info for a default minimal 
configuration a given target require to support all its on-board 
soldered peripherals.  That is hardly arbitrary as those peripherals 
cannot be changed, and their config options are often buried down into 
the Kconfig jungle.

> The best way to free up many hours every day of Linus' time is for one
> person to isolate him from the port maintainers, so that he only has
> to pull (ideally) once per release cycle from one repository.

Possibly, but that's an orthogonal issue to the matter at hand.  It used 
to be RMK who did gather all the patches in addition to his current role 
as the gatekeeper and reviewer for core ARM patches.  And that didn't 
scale as RMK became overworked.  It was then proposed that large 
isolated subarchitecture changes be maintained separately from RMK's 
tree and pulled directly by Linus.

And even if only one person was gathering all the ARM patches together, 
then Linus would still be presented with a humongous amount of lines 
added/changed in arch/arm/configs/* which would still skew the diffstat 
and dirstat, effectively not solving the current issue at all.

What really needs to be done is to remove those defconfig files from the 
code churn picture, so when Linus is asked to pull ARM stuff he's not 
presented with defconfig crap shadowing the real changes.  To achieve 
that, we need to:

1) Collapse as many defconfig files together as possible.  That can be 
   done easily now (even during the -rc period IMHO) with immediate 
   advantages:
   a) reduce the weight of arch/arm/configs/
   b) make fewer machine configs to build for KAutobuild
   c) provide the beginning of a solution to tell Linus that we're 
      concerned too and dealing with the issue.

2) Consider alternative ways to encode those non arbitrary config 
   defaults in a human readable way (that's another of Linus' 
   complaints).  For that, some solutions were proposed, but they won't 
   be developed in a single day like (1) can.

Now the discussion around the ability to compile many machine classes 
(in addition to multiple machines from the same machine class as we 
already can do) together in a single kernel will certainly have some 
effect on the number of defconfig files, but there are other more 
important reasons for doing that other than this issue.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Krzysztof Halasa]

Nicolas Pitre <nico@fluxnic.net> writes:

> Linus wants something to be done about the current defconfig mess which 
> is perfectly legitimate.  He even suggested a possible solution.  I 
> don't think he'll simply drop those defconfig files if we demonstrate 
> that we're taking action to fix the actual problem.

To be honest, I see no usefulness in current defconfigs. Not only ARM
- in any and all defconfigs altogether.

Having this info somewhere on the web, maybe - just like we have the
build logs etc. But in the kernel source tree?

I wonder if I'm the only one frequently doing
grep CONFIG* ... | grep -v defconfig.

I think the issue will fix itself when the "select problem" is fixed.
And we should've fixed the "select problem" long ago (e.g. Kconfig*
should be able to select things without worrying about intermediate
steps, and it should be able to ask the user if needed).
-- 
Krzysztof Halasa

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
> Linus wants something to be done about the current defconfig mess which 
> is perfectly legitimate.  He even suggested a possible solution.  I 
> don't think he'll simply drop those defconfig files if we demonstrate 
> that we're taking action to fix the actual problem.

However, having a set of patches which combine a load of defconfig
files into one is not going to solve the problem.

If you're hypothesis that Linus is only looking at the diffstat, then
what are patches to combine the defconfigs going to do?  It's going
to create lots of noise in arch/arm/configs/ - which is precisely what
Linus is complaining about.  In fact, patch-wise it's going to create
an extremely large patch.  And if we do this time and time again while
progressively reducing the defconfigs.  No, this isn't the answer -
it's only going to make the problem worse.

I believe the only acceptable solution is to get an alterative method
in place - no matter what it is - and remove the all but one of the
defconfig files from the mainline kernel.  _And_, most importantly,
kautobuild needs to be fixed so that we still get build coverage.

The loss of kautobuild is a major concern here, and I believe it trumps
everything else for the next merge window.  Kautobuild is an extremely
important resource that we simply can not afford to lose.

Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [100608 14:53]:
> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
> > Linus wants something to be done about the current defconfig mess which 
> > is perfectly legitimate.  He even suggested a possible solution.  I 
> > don't think he'll simply drop those defconfig files if we demonstrate 
> > that we're taking action to fix the actual problem.
> 
> However, having a set of patches which combine a load of defconfig
> files into one is not going to solve the problem.
> 
> If you're hypothesis that Linus is only looking at the diffstat, then
> what are patches to combine the defconfigs going to do?  It's going
> to create lots of noise in arch/arm/configs/ - which is precisely what
> Linus is complaining about.  In fact, patch-wise it's going to create
> an extremely large patch.  And if we do this time and time again while
> progressively reducing the defconfigs.  No, this isn't the answer -
> it's only going to make the problem worse.
> 
> I believe the only acceptable solution is to get an alterative method
> in place - no matter what it is - and remove the all but one of the
> defconfig files from the mainline kernel.  _And_, most importantly,
> kautobuild needs to be fixed so that we still get build coverage.
> 
> The loss of kautobuild is a major concern here, and I believe it trumps
> everything else for the next merge window.  Kautobuild is an extremely
> important resource that we simply can not afford to lose.

How about the following strategy for the next merge window:

- Update kautobuild to temporarily host the current defconfigs

- Remove all the arm defconfigs except one

Then over the next few merge cycles:

- Make the ARM platform specific Kconfig or similar option to work

- Drop the old defconfigs from kautobuild once we have the new solution

Then over yet unknown lenght of time:

- Work towards building in more features (TLS/SMP/VFPvX) into the same kernel

- Work towards building in multiple ARM platforms into the same kernel

Regards,

Tony

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Tue, Jun 8, 2010 at 8:31 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [100608 14:53]:
>> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
>> > Linus wants something to be done about the current defconfig mess which
>> > is perfectly legitimate. ?He even suggested a possible solution. ?I
>> > don't think he'll simply drop those defconfig files if we demonstrate
>> > that we're taking action to fix the actual problem.
>>
>> However, having a set of patches which combine a load of defconfig
>> files into one is not going to solve the problem.
>>
>> If you're hypothesis that Linus is only looking at the diffstat, then
>> what are patches to combine the defconfigs going to do? ?It's going
>> to create lots of noise in arch/arm/configs/ - which is precisely what
>> Linus is complaining about. ?In fact, patch-wise it's going to create
>> an extremely large patch. ?And if we do this time and time again while
>> progressively reducing the defconfigs. ?No, this isn't the answer -
>> it's only going to make the problem worse.
>>
>> I believe the only acceptable solution is to get an alterative method
>> in place - no matter what it is - and remove the all but one of the
>> defconfig files from the mainline kernel. ?_And_, most importantly,
>> kautobuild needs to be fixed so that we still get build coverage.
>>
>> The loss of kautobuild is a major concern here, and I believe it trumps
>> everything else for the next merge window. ?Kautobuild is an extremely
>> important resource that we simply can not afford to lose.
>
> How about the following strategy for the next merge window:
>
> - Update kautobuild to temporarily host the current defconfigs
>
> - Remove all the arm defconfigs except one
>

This is actually a bit unfair and brutally. The number of defconfig is not
an ARM _only_ problem, although it's a bit significant on ARM due to
the diversity.

ycmiao at macbook-lucid:~/kernel/linux-2.6$ find arch/ -name
"*_defconfig" | grep "arch/sh" | wc -l
50
ycmiao at macbook-lucid:~/kernel/linux-2.6$ find arch/ -name
"*_defconfig" | grep "arch/powerpc" | wc -l
100
ycmiao at macbook-lucid:~/kernel/linux-2.6$ find arch/ -name
"*_defconfig" | grep "arch/mips" | wc -l
47
ycmiao at macbook-lucid:~/kernel/linux-2.6$ find arch/ -name
"*_defconfig" | grep "arch/blackfin" | wc -l
24

Removing all the _defconfig will anyway generate a super BIG patch as
well, which is also going to generate a lot noise in diffstat.

Just wondering if a migration path is possible. Does anyone seriously think
about the solution Linus proposed and maybe we can have an implementation
and have all defconfig going that way before they are completely purged?

> Then over the next few merge cycles:
>
> - Make the ARM platform specific Kconfig or similar option to work
>
> - Drop the old defconfigs from kautobuild once we have the new solution
>
> Then over yet unknown lenght of time:
>
> - Work towards building in more features (TLS/SMP/VFPvX) into the same kernel
>
> - Work towards building in multiple ARM platforms into the same kernel
>
> Regards,
>
> Tony
>

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Tue, Jun 08, 2010 at 08:43:13PM +0800, Eric Miao wrote:
> Just wondering if a migration path is possible. Does anyone seriously think
> about the solution Linus proposed and maybe we can have an implementation
> and have all defconfig going that way before they are completely purged?

Doesn't select from an 'm' symbol cause the target of the select to end
up being 'm' ?  If yes, we have a way to solve this today.

config ARM_PLATFORM_FOO
	bool "Default configuration for FOO"
	select ARCH_FOO
	select VIDEO_WHATEVER

config ARM_PLATFORM_FOO_MOD
	tristate
	default m if ARM_PLATFORM_FOO
	select I2C
	select SPI

etc.  We just need to be very careful about dependencies for things like
I2C, SPI, etc.

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Tue, Jun 8, 2010 at 8:49 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jun 08, 2010 at 08:43:13PM +0800, Eric Miao wrote:
>> Just wondering if a migration path is possible. Does anyone seriously think
>> about the solution Linus proposed and maybe we can have an implementation
>> and have all defconfig going that way before they are completely purged?
>
> Doesn't select from an 'm' symbol cause the target of the select to end
> up being 'm' ? ?If yes, we have a way to solve this today.
>

Have a quick test and it seems to be the case.

> config ARM_PLATFORM_FOO
> ? ? ? ?bool "Default configuration for FOO"
> ? ? ? ?select ARCH_FOO
> ? ? ? ?select VIDEO_WHATEVER
>
> config ARM_PLATFORM_FOO_MOD
> ? ? ? ?tristate
> ? ? ? ?default m if ARM_PLATFORM_FOO
> ? ? ? ?select I2C
> ? ? ? ?select SPI
>
> etc. ?We just need to be very careful about dependencies for things like
> I2C, SPI, etc.
>

Heads up: Linus plans to kill ARM defconfigs

[David John]

On 06/08/2010 05:28 PM, Russell King - ARM Linux wrote:
> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
>> Linus wants something to be done about the current defconfig mess which 
>> is perfectly legitimate.  He even suggested a possible solution.  I 
>> don't think he'll simply drop those defconfig files if we demonstrate 
>> that we're taking action to fix the actual problem.
> 
> However, having a set of patches which combine a load of defconfig
> files into one is not going to solve the problem.
> 
> If you're hypothesis that Linus is only looking at the diffstat, then
> what are patches to combine the defconfigs going to do?  It's going
> to create lots of noise in arch/arm/configs/ - which is precisely what
> Linus is complaining about.  In fact, patch-wise it's going to create
> an extremely large patch.  And if we do this time and time again while
> progressively reducing the defconfigs.  No, this isn't the answer -
> it's only going to make the problem worse.
> 

Hi,

I don't know if this is acceptable and it's just a suggestion - Once the
defconfig 'mess' is fixed, why not move it to Documentation/arm/configs
or somewhere similar where it won't interfere with the arch diffstat?

Regards,
David.

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Tue, Jun 8, 2010 at 8:43 PM, David John <davidjon@xenontk.org> wrote:
> On 06/08/2010 05:28 PM, Russell King - ARM Linux wrote:
>> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
>>> Linus wants something to be done about the current defconfig mess which
>>> is perfectly legitimate. ?He even suggested a possible solution. ?I
>>> don't think he'll simply drop those defconfig files if we demonstrate
>>> that we're taking action to fix the actual problem.
>>
>> However, having a set of patches which combine a load of defconfig
>> files into one is not going to solve the problem.
>>
>> If you're hypothesis that Linus is only looking at the diffstat, then
>> what are patches to combine the defconfigs going to do? ?It's going
>> to create lots of noise in arch/arm/configs/ - which is precisely what
>> Linus is complaining about. ?In fact, patch-wise it's going to create
>> an extremely large patch. ?And if we do this time and time again while
>> progressively reducing the defconfigs. ?No, this isn't the answer -
>> it's only going to make the problem worse.
>>
>
> Hi,
>
> I don't know if this is acceptable and it's just a suggestion - Once the
> defconfig 'mess' is fixed, why not move it to Documentation/arm/configs
> or somewhere similar where it won't interfere with the arch diffstat?
>

That's doable but my understanding is once it is fixed, the configs each
platform needs are actually encoded by the fix already. And the git history
can serve as a reference.

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Tue, 8 Jun 2010, David John wrote:

> On 06/08/2010 05:28 PM, Russell King - ARM Linux wrote:
> > On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
> >> Linus wants something to be done about the current defconfig mess which 
> >> is perfectly legitimate.  He even suggested a possible solution.  I 
> >> don't think he'll simply drop those defconfig files if we demonstrate 
> >> that we're taking action to fix the actual problem.
> > 
> > However, having a set of patches which combine a load of defconfig
> > files into one is not going to solve the problem.
> > 
> > If you're hypothesis that Linus is only looking at the diffstat, then
> > what are patches to combine the defconfigs going to do?  It's going
> > to create lots of noise in arch/arm/configs/ - which is precisely what
> > Linus is complaining about.  In fact, patch-wise it's going to create
> > an extremely large patch.  And if we do this time and time again while
> > progressively reducing the defconfigs.  No, this isn't the answer -
> > it's only going to make the problem worse.
> > 
> 
> Hi,
> 
> I don't know if this is acceptable and it's just a suggestion - Once the
> defconfig 'mess' is fixed, why not move it to Documentation/arm/configs
> or somewhere similar where it won't interfere with the arch diffstat?

This would only _move_ the problem instead of fixing it.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Tue, 8 Jun 2010, Russell King - ARM Linux wrote:

> On Fri, Jun 04, 2010 at 04:51:24PM -0400, Nicolas Pitre wrote:
> > Linus wants something to be done about the current defconfig mess which 
> > is perfectly legitimate.  He even suggested a possible solution.  I 
> > don't think he'll simply drop those defconfig files if we demonstrate 
> > that we're taking action to fix the actual problem.
> 
> However, having a set of patches which combine a load of defconfig
> files into one is not going to solve the problem.

It is an absolutely needed first step.

> If you're hypothesis that Linus is only looking at the diffstat, then
> what are patches to combine the defconfigs going to do?  It's going
> to create lots of noise in arch/arm/configs/ - which is precisely what
> Linus is complaining about.  In fact, patch-wise it's going to create
> an extremely large patch.  And if we do this time and time again while
> progressively reducing the defconfigs.  No, this isn't the answer -
> it's only going to make the problem worse.

I don't think that has to reach Linus' tree.  But that greatly helps 
figuring out a common config pattern that can be applied to a group of 
targets.

> I believe the only acceptable solution is to get an alterative method
> in place - no matter what it is - and remove the all but one of the
> defconfig files from the mainline kernel.  _And_, most importantly,
> kautobuild needs to be fixed so that we still get build coverage.

I personally think that your suggestion using STD_CONFIG or similar is a 
good way forward.  Specific needs for given targets can then be 
expressed along with the Kconfig menu item describing that target.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Tue, Jun 08, 2010 at 08:44:52AM -0400, Nicolas Pitre wrote:
> On Tue, 8 Jun 2010, Russell King - ARM Linux wrote:
> > I believe the only acceptable solution is to get an alterative method
> > in place - no matter what it is - and remove the all but one of the
> > defconfig files from the mainline kernel.  _And_, most importantly,
> > kautobuild needs to be fixed so that we still get build coverage.
> 
> I personally think that your suggestion using STD_CONFIG or similar is a 
> good way forward.  Specific needs for given targets can then be 
> expressed along with the Kconfig menu item describing that target.

It would've been nice, but Linus appears to have ruled that option out too.

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Tue, 8 Jun 2010, Russell King - ARM Linux wrote:

> On Tue, Jun 08, 2010 at 08:44:52AM -0400, Nicolas Pitre wrote:
> > On Tue, 8 Jun 2010, Russell King - ARM Linux wrote:
> > > I believe the only acceptable solution is to get an alterative method
> > > in place - no matter what it is - and remove the all but one of the
> > > defconfig files from the mainline kernel.  _And_, most importantly,
> > > kautobuild needs to be fixed so that we still get build coverage.
> > 
> > I personally think that your suggestion using STD_CONFIG or similar is a 
> > good way forward.  Specific needs for given targets can then be 
> > expressed along with the Kconfig menu item describing that target.
> 
> It would've been nice, but Linus appears to have ruled that option out too.

I wouldn't give up on that option just yet though.  I don't think he 
fully understood your idea, and without an actual patch it might be hard 
to understand as well, especially for people who are not used to deal 
with the target varieties we have on ARM.  Linus is also known to change 
his mind when presented with evidences.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Tue, Jun 08, 2010 at 09:01:35AM -0400, Nicolas Pitre wrote:
> I wouldn't give up on that option just yet though.  I don't think he 
> fully understood your idea, and without an actual patch it might be hard 
> to understand as well, especially for people who are not used to deal 
> with the target varieties we have on ARM.  Linus is also known to change 
> his mind when presented with evidences.

The two ideas are very close to each other - and can be generated
together.

If we create something like Linus' preferred solution, we can then do
in the main arch/arm/Kconfig:

config STD_CONFIG
	bool "blah"

if STD_CONFIG

if MACH_WHATEVER
include arch/arm/config/Kconfig.whatever
endif

if MACH_BLAH
include arch/arm/config/Kconfig.blah
endif

endif

which should work as per my idea.

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

On Tue, Jun 8, 2010 at 9:13 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jun 08, 2010 at 09:01:35AM -0400, Nicolas Pitre wrote:
>> I wouldn't give up on that option just yet though. ?I don't think he
>> fully understood your idea, and without an actual patch it might be hard
>> to understand as well, especially for people who are not used to deal
>> with the target varieties we have on ARM. ?Linus is also known to change
>> his mind when presented with evidences.
>
> The two ideas are very close to each other - and can be generated
> together.
>
> If we create something like Linus' preferred solution, we can then do
> in the main arch/arm/Kconfig:
>
> config STD_CONFIG
> ? ? ? ?bool "blah"
>
> if STD_CONFIG
>
> if MACH_WHATEVER
> include arch/arm/config/Kconfig.whatever
> endif
>
> if MACH_BLAH
> include arch/arm/config/Kconfig.blah
> endif
>
> endif
>
> which should work as per my idea.
>

Anyway, we might need a tool to analyze those common config options across all
boards, and those not. Attached is a script used when updating debian kernel
configs, which I found might be useful. The result is still a _big_
mess to sort out
though. Below is what I did:

1. Generating a complete list of configs (updated)
ycmiao at macbook-lucid:~/kernel/linux-2.6$ for i in arch/arm/configs/*;
do j=`echo $i | sed 's/.*configs\/\(.*\)_defconfig/\1/'`; echo $j;
mkdir ../build/tmp; make ARCH=arm O=../build/tmp `basename $i`; make
ARCH=arm O=../build/tmp oldconfig; cp ../build/tmp/.config
../configs/config.$j; rm -fr ../build/tmp; done

2. Use splitconfigs.pl shows the reduction of config options

ycmiao at macbook-lucid:~/kernel/configs$ cat * | wc -l
258408

ycmiao at macbook-lucid:~/kernel/configs$ splitconfig.pl .
Reading config's ...
Merging lists ...
Creating common config ... done.
Creating stub configs ...

ycmiao at macbook-lucid:~/kernel/configs$ cat * | wc -l
142062

3. A config.common includes those options common to all config.* and
the remaining
config.* now only includes those could be different across boards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: splitconfig.pl
Type: application/octet-stream
Size: 2404 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100608/e0b6259d/attachment.obj>

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Tue, 8 Jun 2010, Eric Miao wrote:

> On Tue, Jun 8, 2010 at 9:13 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jun 08, 2010 at 09:01:35AM -0400, Nicolas Pitre wrote:
> >> I wouldn't give up on that option just yet though. ?I don't think he
> >> fully understood your idea, and without an actual patch it might be hard
> >> to understand as well, especially for people who are not used to deal
> >> with the target varieties we have on ARM. ?Linus is also known to change
> >> his mind when presented with evidences.
> >
> > The two ideas are very close to each other - and can be generated
> > together.
> >
> > If we create something like Linus' preferred solution, we can then do
> > in the main arch/arm/Kconfig:
> >
> > config STD_CONFIG
> > ? ? ? ?bool "blah"
> >
> > if STD_CONFIG
> >
> > if MACH_WHATEVER
> > include arch/arm/config/Kconfig.whatever
> > endif
> >
> > if MACH_BLAH
> > include arch/arm/config/Kconfig.blah
> > endif
> >
> > endif
> >
> > which should work as per my idea.
> >
> 
> Anyway, we might need a tool to analyze those common config options across all
> boards, and those not. Attached is a script used when updating debian kernel
> configs, which I found might be useful. The result is still a _big_
> mess to sort out
> though.

I doubt this can be automated.  The idea is to have something human 
readable, and the only information we really care about is the set of 
drivers each individual target needs.

For example, let's have a look at the SheevaPlug target which is quite 
simple.

config MACH_SHEEVAPLUG
	bool "blah"
	if BASE_STUFF=y
	    select MTD_PARTITIONS
	    select MTD_NAND_ORION
	    select MV643XX_ETH
	    select SERIAL_8250_CONSOLE
	    select USB_EHCI_HCD
	    select MMC_MVSDIO
	    select LEDS_GPIO_PLATFORM
	    select RTC_DRV_MV
	    select MV_XOR
	    select CRYPTO_DEV_MV_CESA
	endif

So the idea is really to describe the built-in hardware and 
automatically selects the _minimum_ set of options (including the 
options they depend on) for all that built-in hardware to work properly.  
All the rest is arbitrary and should probably not be encoded in the 
kernel tree.  The rule of thumb here is to specify any driver set that 
otherwise requires the target's data sheet and/or schematics for a 
proper selection.  All the rest such as filesystems, network protocols, 
USB devices and so on are optional stuff that need no particular 
information from that target and therefore need not to be explicitly 
selected here.

Hence with the above you immediately get a sense of what this particular 
hardware target needs in a fairly human readable form without having to 
dig and guess through all the Kconfig options.  And having that 
information next to the very Kconfig entry concerned is also much easier 
to maintain rather than having that located in a separate file.

Yet in this example, it would probably make sense to move RTC_DRV_MV, 
MV_XOR and CRYPTO_DEV_MV_CESA to where CONFIG_ARCH_KIRKWOOD is selected 
instead of repeating those for every Kirkwood target, as those are 
always available since they're built into the SOC and require no 
external wiring.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Daniel Walker]

On Tue, 2010-06-08 at 12:55 -0400, Nicolas Pitre wrote:

> Hence with the above you immediately get a sense of what this particular 
> hardware target needs in a fairly human readable form without having to 
> dig and guess through all the Kconfig options.  And having that 
> information next to the very Kconfig entry concerned is also much easier 
> to maintain rather than having that located in a separate file.


I think this is what Linus wants .. I tested this to make a OK msm
config for trout, and it does that although I didn't boot test it. I
couldn't get the select statement to select inside a choice menu, so I
had to convert to a regular menu.

You use it like this,

KBUILD_KCONFIG=arch/arm/Kconfig.trout make ARCH=arm allnoconfig

For me, I don't like this method.

Daniel

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1f254bd..ce18fb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -206,9 +206,7 @@ config MMU
 # The "ARM system type" choice list is ordered alphabetically by option
 # text.  Please add new entries in the option alphabetic order.
 #
-choice
-	prompt "ARM system type"
-	default ARCH_VERSATILE
+menu "ARM system type"
 
 config ARCH_AAEC2000
 	bool "Agilent AAEC-2000 based"
@@ -794,7 +792,7 @@ config PLAT_SPEAR
 	help
 	  Support for ST's SPEAr platform (SPEAr3xx, SPEAr6xx and SPEAr13xx).
 
-endchoice
+endmenu
 
 #
 # This is sorted alphabetically by mach-* pathname.  However, plat-*
diff --git a/arch/arm/configs/Kconfig.trout b/arch/arm/configs/Kconfig.trout
new file mode 100644
index 0000000..cf81793
--- /dev/null
+++ b/arch/arm/configs/Kconfig.trout
@@ -0,0 +1,12 @@
+
+config TROUT_BASE_CONFIG
+	bool
+	default y
+	select ARCH_MSM
+	select ARCH_MSM7X00A 
+	select MACH_TROUT
+	select MSM_DEBUG_UART3
+	select MMC
+	select MMC_MSM7X00A
+
+source "arch/arm/Kconfig"

Heads up: Linus plans to kill ARM defconfigs

[Christer Weinigel]

On 06/08/2010 01:58 PM, Russell King - ARM Linux wrote:

> If you're hypothesis that Linus is only looking at the diffstat, then
> what are patches to combine the defconfigs going to do?  It's going
> to create lots of noise in arch/arm/configs/ - which is precisely what
> Linus is complaining about.  In fact, patch-wise it's going to create
> an extremely large patch.  And if we do this time and time again while
> progressively reducing the defconfigs.  No, this isn't the answer -
> it's only going to make the problem worse.


Linus isn't stupid.  If you explain what you are doing and that the goal 
is to reduce the set of defconfigs to just one per processor family, and 
that it will reduce the churn in the end, I think Linus will listen.

Actually, why not just ask Linus if the the way Ben Dooks has structured 
the Samsung defconfigs would be ok with him.  It's only one defconfig 
per CPU family and each defconfig supports a lot of boards.
s3c2410_defconfig supports most ARM9 based Samsung SoCs, S3C2410, 
S3C2412, S3C2413, S3C2440 and S3C2442, all in all some 20-odd boards. 
So for someone who wants to start a new S3C port they can just use the 
s3c2410_defconfig as a base, which I think is how Linus want's the 
defconfigs to be used.

   /Christer

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Tue, Jun 08, 2010 at 02:50:55PM +0200, Christer Weinigel wrote:
> Linus isn't stupid.  If you explain what you are doing and that the goal  
> is to reduce the set of defconfigs to just one per processor family, and  
> that it will reduce the churn in the end, I think Linus will listen.

Linus has said in no uncertain terms that all but one or two ARM defconfigs
will be deleted at the next merge window.  That's not "one or two defconfigs
per platform class".

> Actually, why not just ask Linus if the the way Ben Dooks has structured  
> the Samsung defconfigs would be ok with him.  It's only one defconfig  
> per CPU family and each defconfig supports a lot of boards.

When you look at what Linus is complaining about in the diffstat, you
realise that the S3C stuff is part of the problem.  This is what the
diffstat for arch/arm/configs looks like for the period covering
2.6.34 to 2.6.35-rc1 - which is the one which provoked Linus' reaction.

 arch/arm/configs/am3517_evm_defconfig        |  144 +++-
 arch/arm/configs/ams_delta_defconfig         |   10 +-
 arch/arm/configs/cns3420vb_defconfig         |  831 +++++++++++++
 arch/arm/configs/devkit8000_defconfig        |  157 ++-
 arch/arm/configs/mmp2_defconfig              |   75 +-
 arch/arm/configs/mx51_defconfig              |   17 +-
 arch/arm/configs/omap3_defconfig             |  151 ++-
 arch/arm/configs/omap3_evm_defconfig         |   51 +-
 arch/arm/configs/omap3_stalker_lks_defconfig | 1691 ++++++++++++++++++++++++++
 arch/arm/configs/omap_4430sdp_defconfig      |  448 +++++++-
 arch/arm/configs/rx51_defconfig              |   39 +-
 arch/arm/configs/s3c2410_defconfig           |  719 ++++++-----
 arch/arm/configs/s3c6400_defconfig           |  637 +++++++++-
 arch/arm/configs/s5p6440_defconfig           |   87 +-
 arch/arm/configs/s5p6442_defconfig           |   66 +-
 arch/arm/configs/s5pc100_defconfig           |  235 +++-
 arch/arm/configs/s5pc110_defconfig           |   52 +-
 arch/arm/configs/s5pv210_defconfig           |   55 +-
 arch/arm/configs/spear300_defconfig          |  773 ++++++++++++
 arch/arm/configs/spear310_defconfig          |  775 ++++++++++++
 arch/arm/configs/spear320_defconfig          |  775 ++++++++++++
 arch/arm/configs/spear600_defconfig          |  760 ++++++++++++
 arch/arm/configs/stamp9g20_defconfig         | 1456 ++++++++++++++++++++++
 23 files changed, 9323 insertions(+), 681 deletions(-)

Notice that almost a third (7/23) of the files were Samsung related.

It's also not just about the number of defconfigs.  Linus had other
valid points too - for example, you can't review the changes to them
properly, because any change to them is far too noisy.  That point
doesn't go away by reducing the number of defconfigs.

> s3c2410_defconfig supports most ARM9 based Samsung SoCs, S3C2410,  
> S3C2412, S3C2413, S3C2440 and S3C2442, all in all some 20-odd boards. So 
> for someone who wants to start a new S3C port they can just use the  
> s3c2410_defconfig as a base, which I think is how Linus want's the  
> defconfigs to be used.

I think Linus has made up his mind about what he wants to see, and that's
what we have to provide him with.  However, if you think you've got a
great alternative, please get involved with the thread on LKML and see if
_you_ can change his mind.

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Russell King - ARM Linux wrote:
> On Tue, Jun 08, 2010 at 02:50:55PM +0200, Christer Weinigel wrote:
>> Linus isn't stupid.  If you explain what you are doing and that the goal  
>> is to reduce the set of defconfigs to just one per processor family, and  
>> that it will reduce the churn in the end, I think Linus will listen.
>
> It's also not just about the number of defconfigs.  Linus had other
> valid points too - for example, you can't review the changes to them
> properly, because any change to them is far too noisy.  That point
> doesn't go away by reducing the number of defconfigs.

Part of the problem with the defconfigs is that they are auto-generated
and contain a lot of useless information. As you point out, diffs on
defconfigs tend to result in a lot of noise which makes viewing changes
very difficult.

Striping the spitz defconfig back for example:

  ryan at okiwi:configs$ wc -l spitz_defconfig
  1820 spitz_defconfig

  ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
"^#" | wc -l
  641

So removing all the comments and non-set options makes the defconfig
about 1/3 the size. If the defconfigs were generated by hand, or a
proper set of tools, then they could be much less verbose and diffs for
things like adding or removing a single config option would actually be
readable.

If we want to have individual board configurations in the kernel, then
the information has to live somewhere. Whether it is defconfig, KConfig,
Documentation, whatever, the information will still take up a similar
amount of space, and the process of moving the information will generate
a load of diffstat noise.

I think deleting defconfigs is a good first step. Although there will be
diffstat noise, it will also be clear that the net result is that
thousands of lines are being removed, which is a good thing. Having a
better way of generating defconfigs (or however the information is
stored) would fix the general problem of diffstat noise when changes are
made.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Russell King - ARM Linux]

On Wed, Jun 09, 2010 at 08:51:07AM +1200, Ryan Mallon wrote:
> Striping the spitz defconfig back for example:
> 
>   ryan at okiwi:configs$ wc -l spitz_defconfig
>   1820 spitz_defconfig
> 
>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
> "^#" | wc -l
>   641
> 
> So removing all the comments and non-set options makes the defconfig
> about 1/3 the size. If the defconfigs were generated by hand, or a
> proper set of tools, then they could be much less verbose and diffs for
> things like adding or removing a single config option would actually be
> readable.

Have you tried to use this stripped back defconfig file?

> I think deleting defconfigs is a good first step. Although there will be
> diffstat noise, it will also be clear that the net result is that
> thousands of lines are being removed, which is a good thing.

You're forgetting that if the defconfigs go, then kautobuild might as
well be taken offline because it'll have nothing to build.  It also
means it'll be pointless participating in the build side of linux-next
since that too won't have any useful build coverage.

And at that point, I won't know if the changes I make to the kernel
start breaking EP93xx or whatever other platform - and the same will
be true for other kernel developers.

What's at stake here is not just a bunch of files in the kernel.  It's
much more than that - it's our build testing coverage.

Of course, if people don't mind kernels being broken, and don't mind
changes not being integrated tested in linux-next, we should delete
the defconfig files right now because they wouldn't be serving much
of a useful purpose.

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Russell King - ARM Linux wrote:
> On Wed, Jun 09, 2010 at 08:51:07AM +1200, Ryan Mallon wrote:
>> Striping the spitz defconfig back for example:
>>
>>   ryan at okiwi:configs$ wc -l spitz_defconfig
>>   1820 spitz_defconfig
>>
>>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
>> "^#" | wc -l
>>   641
>>
>> So removing all the comments and non-set options makes the defconfig
>> about 1/3 the size. If the defconfigs were generated by hand, or a
>> proper set of tools, then they could be much less verbose and diffs for
>> things like adding or removing a single config option would actually be
>> readable.
> 
> Have you tried to use this stripped back defconfig file?

No, I haven't. I'm guessing it doesn't work straight off, but the point
is that the defconfigs do contain a lot of unneeded noise.

>> I think deleting defconfigs is a good first step. Although there will be
>> diffstat noise, it will also be clear that the net result is that
>> thousands of lines are being removed, which is a good thing.
> 
> You're forgetting that if the defconfigs go, then kautobuild might as
> well be taken offline because it'll have nothing to build.  It also
> means it'll be pointless participating in the build side of linux-next
> since that too won't have any useful build coverage.

I'm not suggesting deleting all of the defconfigs, I meant removing them
until we have one or two per mach directory. I haven't used kautobuild,
but surely having to build less kernels to support the same number of
boards is good?

Getting the defconfigs down to one or two per mach is, IMHO, a good
first step. Whatever gets decided as the best approach from there will
be easier since it will be a case of migrating ~30 defconfigs to the new
format rather than ~170. It also has the side effect benefit getting
developers to start writing the mach directories with single kernel
building in mind.

The SPEAr300, for example, couldn't be built into one kernel because of
a bunch of naming conflicts in #defines, etc. The patch series I posted
makes it possible to build all of them into one basically by doing a
mass rename. Yeah, I know, more noise :-), but the result is better. If
we do it once, and do it now, and enforce stricter rules in the future,
then the noise will be far greatly reduced in future, at the cost of
slightly noisier diffstats while it all gets fixed.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Wed, 9 Jun 2010, Ryan Mallon wrote:

> Striping the spitz defconfig back for example:
> 
>   ryan at okiwi:configs$ wc -l spitz_defconfig
>   1820 spitz_defconfig
> 
>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
> "^#" | wc -l
>   641
> 
> So removing all the comments and non-set options makes the defconfig
> about 1/3 the size. If the defconfigs were generated by hand, or a
> proper set of tools, then they could be much less verbose and diffs for
> things like adding or removing a single config option would actually be
> readable.
> 
> If we want to have individual board configurations in the kernel, then
> the information has to live somewhere. Whether it is defconfig, KConfig,
> Documentation, whatever, the information will still take up a similar
> amount of space, and the process of moving the information will generate
> a load of diffstat noise.

Did you see the SheevaPlug example I posted earlier?  It contains only 
10 lines of added information.  Certainly not similar amount of space to 
the existing defconfig files.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Nicolas Pitre wrote:
> On Wed, 9 Jun 2010, Ryan Mallon wrote:
> 
>> Striping the spitz defconfig back for example:
>>
>>   ryan at okiwi:configs$ wc -l spitz_defconfig
>>   1820 spitz_defconfig
>>
>>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
>> "^#" | wc -l
>>   641
>>
>> So removing all the comments and non-set options makes the defconfig
>> about 1/3 the size. If the defconfigs were generated by hand, or a
>> proper set of tools, then they could be much less verbose and diffs for
>> things like adding or removing a single config option would actually be
>> readable.
>>
>> If we want to have individual board configurations in the kernel, then
>> the information has to live somewhere. Whether it is defconfig, KConfig,
>> Documentation, whatever, the information will still take up a similar
>> amount of space, and the process of moving the information will generate
>> a load of diffstat noise.
> 
> Did you see the SheevaPlug example I posted earlier?  It contains only 
> 10 lines of added information.  Certainly not similar amount of space to 
> the existing defconfig files.
> 

Yes. I thought the problem was that Kconfig doesn't work correctly for
this though. Does having 'select MTD_PARTITIONS' automatically cause
CONFIG_MTD to be set? If not, then you basically need to have the full
config option list, which is basically what defconfig is.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Daniel Walker]

On Wed, 2010-06-09 at 11:21 +1200, Ryan Mallon wrote:
> Nicolas Pitre wrote:
> > On Wed, 9 Jun 2010, Ryan Mallon wrote:
> > 
> >> Striping the spitz defconfig back for example:
> >>
> >>   ryan at okiwi:configs$ wc -l spitz_defconfig
> >>   1820 spitz_defconfig
> >>
> >>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
> >> "^#" | wc -l
> >>   641
> >>
> >> So removing all the comments and non-set options makes the defconfig
> >> about 1/3 the size. If the defconfigs were generated by hand, or a
> >> proper set of tools, then they could be much less verbose and diffs for
> >> things like adding or removing a single config option would actually be
> >> readable.
> >>
> >> If we want to have individual board configurations in the kernel, then
> >> the information has to live somewhere. Whether it is defconfig, KConfig,
> >> Documentation, whatever, the information will still take up a similar
> >> amount of space, and the process of moving the information will generate
> >> a load of diffstat noise.
> > 
> > Did you see the SheevaPlug example I posted earlier?  It contains only 
> > 10 lines of added information.  Certainly not similar amount of space to 
> > the existing defconfig files.
> > 
> 
> Yes. I thought the problem was that Kconfig doesn't work correctly for
> this though. Does having 'select MTD_PARTITIONS' automatically cause
> CONFIG_MTD to be set? If not, then you basically need to have the full
> config option list, which is basically what defconfig is.

Yeah, you need all the dependencies .. At least in my testing you do,
since select doesn't auto-select dependencies .. It's still smaller than
the normal defconfig tho.

Daniel

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Wed, 9 Jun 2010, Ryan Mallon wrote:

> Nicolas Pitre wrote:
> > On Wed, 9 Jun 2010, Ryan Mallon wrote:
> > 
> >> Striping the spitz defconfig back for example:
> >>
> >>   ryan at okiwi:configs$ wc -l spitz_defconfig
> >>   1820 spitz_defconfig
> >>
> >>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
> >> "^#" | wc -l
> >>   641
> >>
> >> So removing all the comments and non-set options makes the defconfig
> >> about 1/3 the size. If the defconfigs were generated by hand, or a
> >> proper set of tools, then they could be much less verbose and diffs for
> >> things like adding or removing a single config option would actually be
> >> readable.
> >>
> >> If we want to have individual board configurations in the kernel, then
> >> the information has to live somewhere. Whether it is defconfig, KConfig,
> >> Documentation, whatever, the information will still take up a similar
> >> amount of space, and the process of moving the information will generate
> >> a load of diffstat noise.
> > 
> > Did you see the SheevaPlug example I posted earlier?  It contains only 
> > 10 lines of added information.  Certainly not similar amount of space to 
> > the existing defconfig files.
> > 
> 
> Yes. I thought the problem was that Kconfig doesn't work correctly for
> this though. Does having 'select MTD_PARTITIONS' automatically cause
> CONFIG_MTD to be set? If not, then you basically need to have the full
> config option list, which is basically what defconfig is.

Please read my email again and ponder on the rule of thumb I proposed to 
decide what needs to be explicitly provided.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Nicolas Pitre wrote:
> On Wed, 9 Jun 2010, Ryan Mallon wrote:
> 
>> Nicolas Pitre wrote:
>>> On Wed, 9 Jun 2010, Ryan Mallon wrote:
>>>
>>>> Striping the spitz defconfig back for example:
>>>>
>>>>   ryan at okiwi:configs$ wc -l spitz_defconfig
>>>>   1820 spitz_defconfig
>>>>
>>>>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
>>>> "^#" | wc -l
>>>>   641
>>>>
>>>> So removing all the comments and non-set options makes the defconfig
>>>> about 1/3 the size. If the defconfigs were generated by hand, or a
>>>> proper set of tools, then they could be much less verbose and diffs for
>>>> things like adding or removing a single config option would actually be
>>>> readable.
>>>>
>>>> If we want to have individual board configurations in the kernel, then
>>>> the information has to live somewhere. Whether it is defconfig, KConfig,
>>>> Documentation, whatever, the information will still take up a similar
>>>> amount of space, and the process of moving the information will generate
>>>> a load of diffstat noise.
>>> Did you see the SheevaPlug example I posted earlier?  It contains only 
>>> 10 lines of added information.  Certainly not similar amount of space to 
>>> the existing defconfig files.
>>>
>> Yes. I thought the problem was that Kconfig doesn't work correctly for
>> this though. Does having 'select MTD_PARTITIONS' automatically cause
>> CONFIG_MTD to be set? If not, then you basically need to have the full
>> config option list, which is basically what defconfig is.
> 
> Please read my email again and ponder on the rule of thumb I proposed to 
> decide what needs to be explicitly provided.

I agree that is probably a better solution than the defconfigs. However,
 your SheevaPlug example doesn't really show how big that config list is
going to get. Because Kconfig doesn't properly select dependencies, you
will have to list all of them. Granted, the list will be smaller than a
defconfig file, but the Kconfig files are going to become substantially
larger with this approach.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Wed, 9 Jun 2010, Ryan Mallon wrote:

> Nicolas Pitre wrote:
> > On Wed, 9 Jun 2010, Ryan Mallon wrote:
> > 
> >> Nicolas Pitre wrote:
> >>> On Wed, 9 Jun 2010, Ryan Mallon wrote:
> >>>
> >>>> Striping the spitz defconfig back for example:
> >>>>
> >>>>   ryan at okiwi:configs$ wc -l spitz_defconfig
> >>>>   1820 spitz_defconfig
> >>>>
> >>>>   ryan at okiwi:configs$ grep -v "is not set" spitz_defconfig | grep -v
> >>>> "^#" | wc -l
> >>>>   641
> >>>>
> >>>> So removing all the comments and non-set options makes the defconfig
> >>>> about 1/3 the size. If the defconfigs were generated by hand, or a
> >>>> proper set of tools, then they could be much less verbose and diffs for
> >>>> things like adding or removing a single config option would actually be
> >>>> readable.
> >>>>
> >>>> If we want to have individual board configurations in the kernel, then
> >>>> the information has to live somewhere. Whether it is defconfig, KConfig,
> >>>> Documentation, whatever, the information will still take up a similar
> >>>> amount of space, and the process of moving the information will generate
> >>>> a load of diffstat noise.
> >>> Did you see the SheevaPlug example I posted earlier?  It contains only 
> >>> 10 lines of added information.  Certainly not similar amount of space to 
> >>> the existing defconfig files.
> >>>
> >> Yes. I thought the problem was that Kconfig doesn't work correctly for
> >> this though. Does having 'select MTD_PARTITIONS' automatically cause
> >> CONFIG_MTD to be set? If not, then you basically need to have the full
> >> config option list, which is basically what defconfig is.
> > 
> > Please read my email again and ponder on the rule of thumb I proposed to 
> > decide what needs to be explicitly provided.
> 
> I agree that is probably a better solution than the defconfigs. However,
>  your SheevaPlug example doesn't really show how big that config list is
> going to get. Because Kconfig doesn't properly select dependencies, you
> will have to list all of them.

Let's say it doubles.  So 20 lines instead of 10, which is still 
readable and much much smaller than defconfigs.

But the real solution in this case would be to have another 
Kconfig keyword to automatically select the needed dependencies.

> Granted, the list will be smaller than a
> defconfig file, but the Kconfig files are going to become substantially
> larger with this approach.

Sure.  But there is no problem with that if the growth is made of 
valuable information, which in my example I think it is.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Hendrik Sattler]

Am Mittwoch 09 Juni 2010, 01:21:24 schrieb Ryan Mallon:
> Yes. I thought the problem was that Kconfig doesn't work correctly for
> this though. Does having 'select MTD_PARTITIONS' automatically cause
> CONFIG_MTD to be set? If not, then you basically need to have the full
> config option list, which is basically what defconfig is.

Anybody thought about improving Kconfig to make this possible?
Specifying CONFIG_MTD and CONFIG_MTD_PARTITIONS again and again will just 
repeat information (that CONFIG_MTD_PARTITIONS depends on CONFIG_MTD).
The recursive 'select' could have a different name.

HS

Heads up: Linus plans to kill ARM defconfigs

[Daniel Walker]

On Wed, 2010-06-09 at 08:07 +0200, Hendrik Sattler wrote:
> Am Mittwoch 09 Juni 2010, 01:21:24 schrieb Ryan Mallon:
> > Yes. I thought the problem was that Kconfig doesn't work correctly for
> > this though. Does having 'select MTD_PARTITIONS' automatically cause
> > CONFIG_MTD to be set? If not, then you basically need to have the full
> > config option list, which is basically what defconfig is.
> 
> Anybody thought about improving Kconfig to make this possible?
> Specifying CONFIG_MTD and CONFIG_MTD_PARTITIONS again and again will just 
> repeat information (that CONFIG_MTD_PARTITIONS depends on CONFIG_MTD).
> The recursive 'select' could have a different name.

There is work going on to create a SAT solver because the depends lines
are often expression instead of just specifying a single other config
option. So updating the select to work correctly isn't entirely trivial.

The other thing the SAT solver _could_ do is trivialize the current
defconfig into files to only 10 lines or so depending on which arm ..
For instance a defconfig file for trout under mach-msm (the one I
maintain) would look like this,

CONFIG_MACH_TROUT=y
CONFIG_MSM_DEBUG_UART3=y
CONFIG_MMC_MSM7X00A=y

then the solver would just deduce every other option. So three lines vs.
the current 1800+ lines. The files would become manageable, and readable
since they're so much smaller. However, we would still have all the
current files we have now.

That's all speculation still, since this solver thing doesn't exist yet.
We would have to drive it in this direction.

Daniel

Heads up: Linus plans to kill ARM defconfigs

[Uwe Kleine-König]

Hello,

On Wed, Jun 09, 2010 at 06:32:58AM -0700, Daniel Walker wrote:
> On Wed, 2010-06-09 at 08:07 +0200, Hendrik Sattler wrote:
> > Am Mittwoch 09 Juni 2010, 01:21:24 schrieb Ryan Mallon:
> > > Yes. I thought the problem was that Kconfig doesn't work correctly for
> > > this though. Does having 'select MTD_PARTITIONS' automatically cause
> > > CONFIG_MTD to be set? If not, then you basically need to have the full
> > > config option list, which is basically what defconfig is.
> > 
> > Anybody thought about improving Kconfig to make this possible?
> > Specifying CONFIG_MTD and CONFIG_MTD_PARTITIONS again and again will just 
> > repeat information (that CONFIG_MTD_PARTITIONS depends on CONFIG_MTD).
> > The recursive 'select' could have a different name.
> 
> There is work going on to create a SAT solver because the depends lines
> are often expression instead of just specifying a single other config
> option. So updating the select to work correctly isn't entirely trivial.
> 
> The other thing the SAT solver _could_ do is trivialize the current
> defconfig into files to only 10 lines or so depending on which arm ..
> For instance a defconfig file for trout under mach-msm (the one I
> maintain) would look like this,
> 
> CONFIG_MACH_TROUT=y
> CONFIG_MSM_DEBUG_UART3=y
> CONFIG_MMC_MSM7X00A=y
I removed all lines from all defconfigs that don't affect the resulting
.config basing on .35-rc1.  The diffstat is below.  As far as I checked
there are no added lines and the 'pluses' are only context noise.  So
the defconfigs are down to 124.4 (from 1214.4) lines on average.
You can see the result at

	http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=commitdiff;h=arm/defconfig/reduced-v2.6.35-rc1

I'm currently reducing the defconfigs in .34 to be able to compare the
diffstats between (.34 -> .35-rc1) and between (.34-reduced ->
.35-reduced).  I would expect the diff is more or less the same as with
the Kconfig idea.

Compared to the Kconfig idea I see a few advantages:
 - Assuming that kautobuild would only use a base config + per arch
   selections we would loose compile coverage of e.g. CONFIG_AEABI.
 - I have a script that reduces a config, so there is a bit less manual
   work.
 - No need to change kautobuild

Best regards
Uwe

 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/  |

Heads up: Linus plans to kill ARM defconfigs

[Nicolas Pitre]

On Thu, 10 Jun 2010, Uwe Kleine-K?nig wrote:

> I removed all lines from all defconfigs that don't affect the resulting
> .config basing on .35-rc1.  The diffstat is below.  As far as I checked
> there are no added lines and the 'pluses' are only context noise.  So
> the defconfigs are down to 124.4 (from 1214.4) lines on average.
> You can see the result at
> 
> 	http://git.pengutronix.de/?p=ukl/linux-2.6.git;a=commitdiff;h=arm/defconfig/reduced-v2.6.35-rc1
> 
> I'm currently reducing the defconfigs in .34 to be able to compare the
> diffstats between (.34 -> .35-rc1) and between (.34-reduced ->
> .35-reduced).  I would expect the diff is more or less the same as with
> the Kconfig idea.
> 
> Compared to the Kconfig idea I see a few advantages:
>  - Assuming that kautobuild would only use a base config + per arch
>    selections we would loose compile coverage of e.g. CONFIG_AEABI.

That is not acceptable of course.

Same thing for HIGHMEM, PREEMPT, SMP, etc.

>  - I have a script that reduces a config, so there is a bit less manual
>    work.
>  - No need to change kautobuild
> 
[...]
> 
>  177 files changed, 652 insertions(+), 194157 deletions(-)

That's really nice.


Nicolas

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Hendrik Sattler wrote:
> Am Mittwoch 09 Juni 2010, 01:21:24 schrieb Ryan Mallon:
>> Yes. I thought the problem was that Kconfig doesn't work correctly for
>> this though. Does having 'select MTD_PARTITIONS' automatically cause
>> CONFIG_MTD to be set? If not, then you basically need to have the full
>> config option list, which is basically what defconfig is.
> 
> Anybody thought about improving Kconfig to make this possible?
> Specifying CONFIG_MTD and CONFIG_MTD_PARTITIONS again and again will just 
> repeat information (that CONFIG_MTD_PARTITIONS depends on CONFIG_MTD).
> The recursive 'select' could have a different name.

This could be done by manually fixing the Kconfig files and using the
select keyword to specify mandatory dependencies. For example CONFIG_MTD
should select CONFIG_MTD_PARTITIONS since it cannot work without it. The
MTD_PARTITIONS option will still be hidden until MTD is selected because
of the 'if MTD' at the top of drivers/mtd/Kconfig, but it means the
other Kconfig files doing a select MTD_PARTITIONS would work correctly.

Would be a lot of work to go through all of the Kconfig files and fix
this though.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Catalin Marinas]

On Wed, 2010-06-09 at 07:07 +0100, Hendrik Sattler wrote:
> Am Mittwoch 09 Juni 2010, 01:21:24 schrieb Ryan Mallon:
> > Yes. I thought the problem was that Kconfig doesn't work correctly for
> > this though. Does having 'select MTD_PARTITIONS' automatically cause
> > CONFIG_MTD to be set? If not, then you basically need to have the full
> > config option list, which is basically what defconfig is.
> 
> Anybody thought about improving Kconfig to make this possible?
> Specifying CONFIG_MTD and CONFIG_MTD_PARTITIONS again and again will just
> repeat information (that CONFIG_MTD_PARTITIONS depends on CONFIG_MTD).
> The recursive 'select' could have a different name.

A first step is a warning when selecting options with unmet dependencies
- http://lkml.org/lkml/2010/6/8/191.

This could be extended to automatically select the dependencies but it
many cases it could just be a Kconfig error.

-- 
Catalin

Heads up: Linus plans to kill ARM defconfigs

[Ryan Mallon]

Martin Guy wrote:
> Shame. I was about to post a Sim.One defconfig patch (while fully
> realizing that the choice of options is largely arbitrary. and copied
> ad-hoc from some other similar defconfig). While it's nice to be able
> to tell people "make foobar_defconfig; make (z|u|bz)Image" in reality
> the config is as arbitrary as the root filesystem in use (and should
> be chosen to match it).

Once the support runtime phys offset is merged it will be possible for
ep93xx_defconfig to support all of the ep93xx boards.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

Heads up: Linus plans to kill ARM defconfigs

[Tony Lindgren]

* Eric Miao <eric.y.miao@gmail.com> [100604 10:07]:
> On Fri, Jun 4, 2010 at 2:10 PM, Tony Lindgren <tony@atomide.com> wrote:
> > * Eric Miao <eric.y.miao@gmail.com> [100604 04:35]:
> >>
> >> Also, we are now working on a single kernel for multiple sub-arch (at least
> >> what Nicolas and I am doing now, and welcome to join us). It's tough (the
> >> way to handle different phys_offset is only the tip of the iceberg) and seems
> >> now more and more necessary. so hopefully by the end of the day, we may
> >> possible end up with only very few defconfig.
> >
> > Great, do you have some git branch for that somewhere?
> >
> 
> All the currently done work I've posted to the mailing list:
> 
> 1. SPARSEIRQ
> 2. MULTI_IRQ_HANDLER
> 3. Makefile.boot move to arch/arm/boot/bootp _only_
> 4. RUNTIME_PHYS_OFFSET (not really my work, but Uwe's)
> 
> Nico and I have setup a blueprint and wiki spec for this, I hope more
> can join us with the effort.
> 
> https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-arm-single-zimage
> https://wiki.ubuntu.com/Specs/ARMSingleKernel
> 
> I'll push what I did to
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6.git
> unified-kernel
> 
> But it's a mess now.

OK thanks.
 
> > Parallel to dealing with different phys_offset we can also try combining
> > some two ARM platforms that have the same phy_offset. That already exposes
> > tons of conflicting defines that need to be sorted out..
> >
> 
> A first step to take might be looking at all those machine specific header
> files that will be included into generic <asm/*.h> and in turn included by
> other code. The PHYS_OFFSET is only a small tip of the iceberg I'm afraid.
> A very rough grep and analysis as below:

Nice analysis :) First I need to finish my earlier TLS patch for ARMv6 and 7
binaries, then I'll try to find some time to help on this stuff too.

Tony

Heads up: Linus plans to kill ARM defconfigs

[pieterg]

On Friday 04 June 2010 03:10:14 Marek Vasut wrote:
> I just tested, PXA (mach-pxa) probably can be compiled into single kernel
> supporting all the boards.

For my boards (colibri) I see only one exception; I haven't managed to build 
a single kernel with support for different AC97 chips.

I have to build separate WM9715 and UCB1400 kernels.

Rgds, Pieter

Heads up: Linus plans to kill ARM defconfigs

[Eric Miao]

That's supposed to be possible with ASoC, what's the exact problem?

- eric from G1

On Jun 4, 2010 4:39 PM, "pieterg" <pieterg@gmx.com> wrote:

On Friday 04 June 2010 03:10:14 Marek Vasut wrote:
> I just tested, PXA (mach-pxa) probably can be c...
For my boards (colibri) I see only one exception; I haven't managed to build
a single kernel with support for different AC97 chips.

I have to build separate WM9715 and UCB1400 kernels.

Rgds, Pieter


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at list...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100604/1bebde89/attachment-0001.htm>

Heads up: Linus plans to kill ARM defconfigs

[Daniel Mack]

On Fri, Jun 04, 2010 at 10:36:39AM +0200, pieterg wrote:
> On Friday 04 June 2010 03:10:14 Marek Vasut wrote:
> > I just tested, PXA (mach-pxa) probably can be compiled into single kernel
> > supporting all the boards.
> 
> For my boards (colibri) I see only one exception; I haven't managed to build 
> a single kernel with support for different AC97 chips.

Which problems did you have when tring this?

Daniel

Heads up: Linus plans to kill ARM defconfigs

[pieterg]

On Friday 04 June 2010 10:56:29 Daniel Mack wrote:
> On Fri, Jun 04, 2010 at 10:36:39AM +0200, pieterg wrote:
> > On Friday 04 June 2010 03:10:14 Marek Vasut wrote:
> > > I just tested, PXA (mach-pxa) probably can be compiled into single
> > > kernel supporting all the boards.
> >
> > For my boards (colibri) I see only one exception; I haven't managed to
> > build a single kernel with support for different AC97 chips.
>
> Which problems did you have when tring this?

Hm, thanks for making me try this again. I was convinced a UCB1400 
touchscreen was not recognised when I had CONFIG_TOUCHSCREEN_WM97XX in the 
config, but trying this again now shows it works fine.
I must have drawn the wrong conclusion back then.
Glad I can use a single config for my boards now.

Rgds, Pieter