linux-kernel - Re: [PATCH v2 1/2] crypto: qat

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: <ZO375Wg0+nTCgCIJ@smile.fi.intel.com>
Date:   Tue, 29 Aug 2023 17:08:37 +0300
From:   Andy Shevchenko <andriy.shevchenko@...el.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Lucas Segarra Fernandez <lucas.segarra.fernandez@...el.com>,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        qat-linux@...el.com, alx@...nel.org,
        Giovanni Cabiddu <giovanni.cabiddu@...el.com>
Subject: Re: [PATCH v2 1/2] crypto: qat - refactor included headers

On Tue, Aug 29, 2023 at 06:18:24PM +0800, Herbert Xu wrote:
> On Mon, Aug 28, 2023 at 01:46:18PM +0300, Andy Shevchenko wrote:
> >
> > kernel.h is misleading here. It includes 98% of something which this file is
> > not using or going to use. Can you tell _why_ we need that 98% bulk to be
> > included here?
> 
> For most drivers in drivers/crypto they will need multiple header
> files included by kernel.h.  I'd hate for people to start posting
> patches replacing one inclusion of kernel.h with multiple inclusions.
> 
> They're bound to get it wrong and we'll be forever dealing with
> random build failures because someone changes a random header
> elsewhere which then exposes a missed inclusion.

Do I understand correctly that you want *ideally* to have THE kernel.h
as a _single_ header and that's it?

While I understand your motivation as a maintainer, I hate the idea of current
kernel.h to be included as a silver bullet to every file because people are not
capable to understand this C language part of design. The usage of the proper
headers show that developer _thought_ very well about what they are doing in
the driver. Neglecting this affects the quality of the code in my opinion.
That's why I strongly recommend to avoid kernel.h inclusion unless it's indeed
the one that provides something that is used in the driver. Even though, the
rest headers also need to be included (as it wasn't done by kernel.h at any
circumstances).

-- 
With Best Regards,
Andy Shevchenko