linux-kernel - Re: [PATCH 00/17] Add memberof(), split some headers, and slightly simplify code

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:   Fri, 19 Nov 2021 17:49:51 +0100
From:   "Alejandro Colomar (man-pages)" <alx.manpages@...il.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Arnd Bergmann <arnd@...db.de>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/17] Add memberof(), split some headers, and slightly
 simplify code



On 11/19/21 17:37, Andy Shevchenko wrote:
> On Fri, Nov 19, 2021 at 05:12:19PM +0100, Alejandro Colomar (man-pages) wrote:
>> On 11/19/21 16:57, Arnd Bergmann wrote:
> 
> ...
> 
>>> On the plus side, I did see something on the order of a 30%
>>> compile speed improvement with clang, which is insane
>>> given that this only removed dead definitions.
>>
>> Huh!
>>
>> I'd like to see the kernel some day
>> not having _any_ hidden dependencies.
> 
> It's neither feasible nor practical. If we know the hard dependencies between
> headers, why should we not use implicit inclusion?
> 
> We all know that bitmap.h includes bitops.h and this is good and a must, why
> to avoid this?
> 

Well, none at all may be too much.
But being close to it would simplify much changing and especially
understanding the code.

At least avoiding 10 levels of indirection of includes
would be a good start :)

-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/