lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070906211955.GF4480@stusta.de>
Date:	Thu, 6 Sep 2007 23:19:55 +0200
From:	Adrian Bunk <bunk@...nel.org>
To:	Oleg Verych <olecom@...wer.upol.cz>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>, sam@...nborg.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] build system: section garbage collection for
	vmlinux

On Thu, Sep 06, 2007 at 11:16:15PM +0200, Oleg Verych wrote:
> * Thu, 6 Sep 2007 22:39:31 +0200
> 
> []
> >> > His patch improves the build process.
> >> 
> >> I would like to know timing, btw. Size, especially shown 1%, doesn't
> >> matter if link time increased dramatically. `Allyes' config, when i
> >> had fast and rammish machine was terrible thing (last winter). If 32
> >> cores/cpus is will of author, then i'm even more suspicious.
> >
> > For non-developers size and speed of the kernel matter much more than 
> > compile time.
> 
> I'm talking about benefits for the process (developers, testers) and
> the result (end users, dogs eating own food :).

Your claim was that link time was more important than code size, and 
that claim is in many cases wrong.

> > When you go towards embedded systems with limited resources a 1% size 
> > decrease would often be worth it even if it would (hypothetically) 
> > increase the compile time by a factor of 10.
> 
>    text    data     bss     dec     hex filename
>    5159478 1005139  406784 6571401  644589 linux-2.6.23-rc4.org/vmlinux
>    5131822  996090  401439 6529351  63a147 linux-2.6.23-rc4.gc/vmlinux
> 
> Are this numbers show embedded target? I think no. Also time factor of
> *10* can be spent more productively reviewing actual code of parts, that
> are going to be embedded, no?

First of all, please lookup the word "hypothetically" in a dictionary.

And code review and Denys' patch have cumulative effects since his patch 
results in improvements that can't be resonably done other than at 
the ld and/or gcc level.

> []
> >> > There's nothing that requires treatment.
> >> 
> >> [Help for] The developers/contributors of those drivers, no?
> >>...
> >
> > They did everything right.
> >
> > You should better try to understand the problem first before behaving as 
> > if you knew everything better than everyone else...
> 
> OK, thank you very much. Now, describe what problem you are talking
> about, please. I see non.

If you don't understand what the patches in this thread are about then 
you shouldn't have started commenting on this thread...

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ