To a large extent, I agree. I certainly don't want to focus solely on

code size; there's a lot more to embedded Linux than that. But it _is_

an issue. 
There are some cases where we really _do_ want to have CONFIG options,

but I agree that we should keep them to a minimum. And when we _do_ have

CONFIG options, they don't have to litter the actual code with ifdefs.

We're quite capable of having "function calls" which in some
He wasn't talking about one specific system. There'll be an element of
Stuff like shrinking the rbtree structure by encoding the colour in the
Potentially at a cost of higher boot time, which is another
I've never been that convinced about XIP. Flash is more expensive than

RAM, and cheap flash is NAND and not XIP-able these days anyway. The

only really convincing motivation for XIP would be the _power_ budget,

and if your power budget is _that_ tight, then often you'd be better off
Don't worry -- we're not going to start seeing a flurry of patches

adding CONFIG options and turning Linux into #ifdef hell :)
--

dwmw2
--

Not only code size, far more important is dynamic memory consumption.
The problem I see is more that really nobody can even compile not

alone test all these combinations anymore. Hidding the problem in inlines
Whatever pays off.
-Andi

--

Because we allowed kernel to be developed without the requirement that

random config should be buildable for release kernels.
Had it been a requirement, keeping it in shape wouldn't be

too difficult.
Sure enough, _now_ fixing kernel to pass such a test on i386

would take several weeks of work at least. But it is doable.
I would even volunteer to do it if there are some

reasonable chances resulting patches would be viewed

as worthwhile for inclusion. I am somewhat tired

of killing weeks of my time only to find that my work

is deemed "not important enough for inclusion".

--

vda

--

On i386 it might even already work today.
But guess how much time it costs to get at least all defconfigs

compiling on the other 22 architectures.
Even getting allmodconfig/allyesconfig compiling isn't trivial for all

architectures, and random configurations are _far_ from compiling.
And we are not talking about something to be done once, as soon as you

leave x86 there are tons of regular breakages.
Plus the fact that you often get into situations where more options

mean complex and fragile stuff. Read the Kconfig files under

drivers/media/ and check in git all commits to them since 2.6.25 alone,

and you'll understand why "add an option for every bit" can result in

very high ongoing maintainance work required.
Not everything that is technically possible is also maintainable, and

maintainability is a very important point in a project with several 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

>

 > And we are not talking about something to be done once, as soon as you

 > leave x86 there are tons of regular breakages.
Could automated builds and build error reporting be used to help resolve

these problems?
The good people at Simtec have an automated build report available as an

e-mail digest. I use it to watch for architecture build breakages in

subsystems or drivers that I use or touch. It covers defconfigs of ARM

and MIPS architectures and reports compile errors/warnings, module size,

kernel size etc. If this approach were extended/distributed to cover

more architectures and random config builds, developers could with

little effort spot problems and fix them. Hell, it might also encourage

new developers to get involved and contribute.
Here's a link to a recent report for ARM, fyi:-
--

James Chapman

Katalix Systems Ltd

http://www.katalix.com

Catalysts for your Embedded Linux software development
--

Jan Dittmer has a great page showing the build status and kernel size of

the defconfigs of all architectures that is running since 2004 or 2005:
Perhaps in an ideal world...
In reality, I'd claim I'm one out of only two people who regularly fix 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

OK sure.  Nobody's going to disagree with that.  I would, however,

disagree with a characterization of Linux-tiny as "adding an option

for every bit".  Linux-tiny has been around about 5 years now, and

if you added the whole thing right now you'd add about 30 config

options.
If you're worried about this multiplying out of control, let me

just say that having to curtail the rate of patch submission by

embedded developers has not been our biggest problem.  :-)

 -- Tim
=============================

Tim Bird

Architecture Group Chair, CE Linux Forum

Senior Staff Engineer, Sony Corporation of America

=============================
--

Well, I am not (and was not) disputing this. I agree with it.

CONFIGs should not be multiplying like rabbits.

--

vda

--

Hi Andi,
There's a Google Summer of Code project going on now to implement such

instrumentation:
http://code.google.com/soc/2008/linux/appinfo.html?csaid=E749E676AD70FBB0
So any suggestions/input on this is obviously welcome.

--

Hi,
I'm the student working on this. I have already implemented tracing for

SLAB, SLUB and SLOB, and patched relayfs to work early on (just after

kmem_cache_init() runs). Currently, I'm working on the userspace tool,

so much of the coding is largely finished.
I wanted to submit the relay stuff, but couldn't contact its maintainer.
If anyone wants to take a look, I could set up a git repo somewhere

(which has to be done anyway, at some point).
	Cheers,

	Eduard
On Fri, 2 May 2008 18:00:43 +0300

--

On Fri, 2 May 2008 23:01:41 +0300
Send a patch as per Documentation/SubmittingPatches to
	Andrew Morton <akpm@linux-foundation.org>

	linux-kernel@vger.kernel.org

	Tom Zanussi <zanussi@us.ibm.com>
and magic will happen.
<looks in ./MAINTAINERS>

<looks at Tom>

--

On Fri, 2 May 2008 13:14:47 -0700
I said I couldn't contact the maintainer, not that I don't know who's

the maintainer :-).
Unfortunately both e-mail addresses of Tom Zanussi don't work (for me).

Comcast won't accept my mails (though my mail provider's server looks

fine to others), and IBM says there's no 'zanussi' in their directory.
I will try again, but will you merge it / contact him otherwise if I

find it impossible? Anyway, you will be Cc-ed when I do.
BTW, Mathieu Desnoyers is also aware of my patch, and he looked

interested in it, if this matters.

--

On Fri, 2 May 2008 23:33:30 +0300
Yeah, stuff happens.  It never hurts to cc me - I'm kind of the team
--

How did you do that?
His most recent emails are from

Tom Zanussi <tzanussi@gmail.com> and
---

~Randy

--

Quite a lot of kernel developers use quite a lot of email addresses and

it's rather a pita.  People perhaps underestimate the value of not being a

moving target.
--