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

Message-ID: <CAH2r5mu13Jva4nP-rdk3QeRe=Y5iE6RcM7txKdRDHJM8a6AoBQ@mail.gmail.com>
Date: Mon, 1 Dec 2025 12:16:44 -0600
From: Steve French <smfrench@...il.com>
To: Enzo Matsumiya <ematsumiya@...e.de>
Cc: David Howells <dhowells@...hat.com>, 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?

I don't have much objection about #1 and $2, 3 possibly if not huge,
but higher priority is 4.  Agree that 5 and 6 are lowest priority
unless part of patch that is fixing (or perf improvement etc.)
something

On Mon, Dec 1, 2025 at 11:32 AM Enzo Matsumiya <ematsumiya@...e.de> wrote:
>
> 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
>


-- 
Thanks,

Steve