linux-kernel - Re: [PATCH] prepare kconfig inline optimization for all architectures

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Apr 2008 20:47:14 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	linux arch <linux-arch@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] prepare kconfig inline optimization for all
	architectures

On Sun, Apr 27, 2008 at 10:32:28AM -0700, Linus Torvalds wrote:
> 
> 
> On Sun, 27 Apr 2008, Adrian Bunk wrote:
> > 
> > I'm looking at it from a different angle, all code in the kernel should 
> > follow the following rules [1]:
> > - no functions in .c files should be marked inline
> > - all functions in headers should be static inline
> > - all functions in headers should either be very small or collapse
> >   to become very small after inlining
> > 
> > I can simply not see any usecase for a non-forced inline in the kernel,
> > and fixing the kernel should give a superset of the space savings of 
> > this "inline optimization".
> 
> Your whole argument is premised on the assumption that the compiler does 
> the right thing.
>...

No, you seem to be misunderstanding what I am saying.

Status Quo as of 2.6.25:
- we force the compiler to always inline with "inline"
- we have inline's in .c files and too big functions in headers, and
  both of them are wrong

"inline optimization":
- we leave the compiler the choice whether or not to inline with "inline"
- we still have inline's in .c files and too big functions in headers, 
  and both of them are wrong, but this "inline optimization" works 
  around these in some of the cases

What I want instead:
- we continue to force the compiler to always inline with "inline"
- we remove the inline's in .c files and make too big functions in 
  headers out-of-line

> 			Linus

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/