Message-ID: <20080731164918.GE20212@cs181140183.pp.htv.fi>
Date:	Thu, 31 Jul 2008 19:49:18 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	michael@...e-electrons.com, Matt Mackall <mpm@...enic.com>,
	matthew@....cx, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [patch 2/4] Configure out file locking features

On Thu, Jul 31, 2008 at 06:26:16PM +0200, Thomas Petazzoni wrote:
> Le Thu, 31 Jul 2008 18:37:57 +0300,
> Adrian Bunk <bunk@...nel.org> a écrit :
> 
> > I'm just not a fan of adding config options for each few kB of code - 
> > we have to maintain them and the more complex the configuration
> > becomes the more often it breaks.
> 
> I'm not a fan of these too, but are there other solutions ?

There are many things that can be done to reduce the kernel size or try 
to minimize the growth of the kernel.

E.g. working on --combine -fwhole-program (where David once had 
preliminary patches for the per-module approach) might be better.

> > What became bigger was most likely not related to the patches you
> > sent.
> 
> No, it is not.
> 
> > Where and why did the kernel become bigger?
> 
> It's not up-to-date with 2.6.26 and 2.6.27-rc1, but Bloatwatch
> <http://www.selenic.com/bloatwatch/>, by Matt Mackall, is here to
> answer these questions. I haven't made the analysis for
> 2.6.26->2.6.27-rc1.

It can only give some hints where to start searching.

But it tracks a defconfig, and e.g. the nearly doubled size between
2.6.18 and 2.6.19 is both expected and not a problem for embedded
systems.

The real work is to figure out in which areas that are relevant for 
embedded systems the kernel became bigger.

> > Why did CONFIG_FW_LOADER get enabled?
> > Due to alnoconfig disabling CONFIG_EMBEDDED?
> 
> I don't know. Haven't made the analysis for now.
> 
> > A user will ask:
> > I'm using $applications with $libraries, can I safely disable this
> > option?
> 
> Hard to tell in the general case.
> 
> > And e.g. according to a quick grep through the sources uClibc's 
> > updwtmp() seems to cease working without flock().
> 
> Correct. But on many embedded systems, we don't care about logging past
> user logins. We might even not care about logins at all.

And for embedded systems with which applications is it 100% safe to 
disable this option?

And don't answer "doesn't use flock()", I want a real-life example of a 
device where you could guarantee a developer that disabling this option 
in his product would be safe.

> > It costs us maintainance of the option and the #ifdef's and gives
> > users one way more to shoot themselves into the foot in nontrivial to
> > detect ways.
> 
> That's correct, and as I said previously, I fully understand the
> maintainance problem of all these new configuration options. I must
> admit that I do not really have more objective technical arguments that
> would help us deciding whether the code size reduction vs. code
> maintainance choice should be made in one direction or the other.

My personal criteron for this patch is still how many real-life systems 
can safely disable it.

> Sincerly,
> 
> Thomas

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists