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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux