linux-kernel - Re: Can we sort out the prototypes within the cifs headers?

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: <qvtkweac7g5ejiicsnb7cqxlxl35toi2ykdmguaszqkcnir355@zvaw3oxlxzex>
Date: Mon, 1 Dec 2025 14:30:59 -0300
From: Enzo Matsumiya <ematsumiya@...e.de>
To: David Howells <dhowells@...hat.com>
Cc: Paulo Alcantara <pc@...guebit.org>, Steve French <sfrench@...ba.org>, 
	Shyam Prasad N <sprasad@...rosoft.com>, Stefan Metzmacher <metze@...ba.org>, linux-cifs@...r.kernel.org, 
	netfs@...ts.linux.dev, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Can we sort out the prototypes within the cifs headers?

Hi David,

On 12/01, David Howells wrote:
>Hi Paulo, Enzo, et al.,
>
>You may have seen my patch:
>
>	https://lore.kernel.org/linux-cifs/20251124124251.3565566-4-dhowells@redhat.com/T/#u
>
>to sort out the cifs header file prototypes, which are a bit of a mess: some
>seem to have been placed haphazardly in the headers, some have unnamed
>arguments and also sometimes the names in the .h and the .c don't match.
>
>Now Steve specifically namechecked you two as this will affect the backporting
>of patches.  Whilst this only affects the prototypes in the headers and not
>the implementations in C files, it does cause chunks of the headers to move
>around.
>
>Can we agree on at least a subset of the cleanups to be made?  In order of
>increasing conflictiveness, I have:
>
> (1) Remove 'extern'.  cifs has a mix of externed and non-externed, but the
>     documented approach is to get rid of externs on prototypes.
>
> (2) (Re)name the arguments in the prototypes to be the same as in the
>     implementations.
>
> (3) Adjust the layout of each prototype to match the implementation, just
>     with a semicolon on the end.  My script partially does this, but moves
>     the return type onto the same line as the function name.
>
> (4) Move SMB1-specific functions out to smb1proto.h.  Move SMB2/3-specific
>     functions out to smb2proto.h.
>
> (5) Divide the lists of prototypes (particularly the massive one in
>     cifsproto.h) up into blocks according to which .c file contains the
>     implementation and preface each block with a comment that indicates the
>     name of the relevant .c file.
>
>     The comment could then be used as a key for the script to maintain the
>     division in future.
>
> (6) Sort each block by position in the .c file to make it easier to maintain
>     them.
>
>A hybrid approach is also possible, where we run the script to do the basic
>sorting and then manually correct the output.

+1 for the cleanups, thanks for doing that.

On backports, I think points 1-3 could be done together, but in separate
commits (per header file) to minimise conflicts.

4 looks good to have.

5-6 would be most problematic (moving code around).

Not sure what else to say here, but more atomic commit are easier to
backport than big/monolithic ones.


Cheers,

Enzo