Re: [RFC 3/3] headers: repurpose linux/fs_types.h

[Christian Brauner]

On Wed, Dec 08, 2021 at 11:10:26AM +0100, Arnd Bergmann wrote:
> On Wed, Dec 8, 2021 at 11:05 AM Christian Brauner
> <christian.brauner@xxxxxxxxxx> wrote:
> >
> > On Tue, Dec 07, 2021 at 04:09:27PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@xxxxxxxx>
> > >
> > > linux/fs_types.h traditionally describes the types of file systems we
> > > deal with, but the file name could also be interpreted to refer to
> > > data types used for interacting with file systems, similar to
> > > linux/spinlock_types.h or linux/mm_types.h.
> > >
> > > Splitting out the data type definitions from the generic header helps
> > > avoid excessive indirect include hierarchies, so steal this file
> > > name and repurpose it to contain the definitions for file, inode,
> > > address_space, super_block, file_lock, quota and filename, along with
> > > their respective callback operations, moving them out of linux/fs.h.
> > >
> > > The preprocessed linux/fs_types.h is now about 50KB, compared to
> > > over 1MB for the traditional linux/fs.h, and can be included from
> > > most other headers that currently rely on type definitions from
> > > linux/fs.h.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> > > ---
> >
> > I tried to apply the series to take a closer look but it fails to apply
> > cleanup down to v5.15 and any release after that. What's the base I
> > should use for this?
> 
> It is based on yesterday's linux-next plus additional patches I used
> for testing. Sorry about the extra troubles, but this was the most

No no, that's perfectly fine!

> convenient way for me, as it lets me find build regressions in random
> configs more easily when I have a base tree that builds randconfig
> warning-free.
> 
> The patches are at the top of my randconfig tree [1] at the moment,
> so you can try out that tree, or rebase the patches from there.
> 
>         Arnd
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=randconfig-5.17-next

Thanks for pointing me in the right direction.

Christian