linux-kernel - Re: [PATCH 1/1] PCI: pciehp: Consolidate code files

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] [day] [month] [year] [list]

Message-ID: <aCH7_J4GE112pyCc@wunner.de>
Date: Mon, 12 May 2025 15:47:40 +0200
From: Lukas Wunner <lukas@...ner.de>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Shawn Anastasio <sanastasio@...torengineering.com>,
	Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
	Krzysztof Wilczy??ski <kw@...ux.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/1] PCI: pciehp: Consolidate code files

On Mon, May 12, 2025 at 03:45:28PM +0300, Ilpo Järvinen wrote:
> The code in the pciehp driver is a bit painful to read because of the
> criss-cross calls that cross file boundaries making the split to
> multiple files feel quite artificial.
> 
> Consolidate the code into single pciehp.c. The split files are not
> simply merged as is but the functions are grouped based on
> functionality and order that avoids most forward declarations.
[...]
>  drivers/pci/hotplug/Makefile      |    5 -
>  drivers/pci/hotplug/pciehp.c      | 2151 +++++++++++++++++++++++++++++
>  drivers/pci/hotplug/pciehp.h      |  212 ---
>  drivers/pci/hotplug/pciehp_core.c |  383 -----
>  drivers/pci/hotplug/pciehp_ctrl.c |  445 ------
>  drivers/pci/hotplug/pciehp_hpc.c  | 1123 ---------------
>  drivers/pci/hotplug/pciehp_pci.c  |  141 --
>  7 files changed, 2151 insertions(+), 2309 deletions(-)

Ugh, I understand that the current state is suboptimal to grok the code,
but a single file with 2000+ LoC isn't much better in terms of
maintainability.  I think partitioning the code into separate files
does make sense, just the current (historically grown) structure
can be improved upon.  Let me think what a more logical separation
might look like...

Thanks,

Lukas