Re: [patch 2/4] Configure out file locking features

From: Adrian Bunk
Date: Thu Jul 31 2008 - 12:50:33 EST


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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/