Re: [RFC PATCH 4/7] mm: move internal core VMA manipulation functions to own file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Lorenzo Stoakes <lstoakes@xxxxxxxxx> [240627 15:41]:
> On Thu, Jun 27, 2024 at 01:56:12PM -0400, Liam R. Howlett wrote:
> > * Lorenzo Stoakes <lstoakes@xxxxxxxxx> [240627 06:39]:
> > > This patch introduces vma.c and moves internal core VMA manipulation
> > > functions to this file from mmap.c.
> > >
> > > This allows us to isolate VMA functionality in a single place such that we
> > > can create userspace testing code that invokes this functionality in an
> > > environment where we can implement simple unit tests of core functionality.
> > >
> > > This patch ensures that core VMA functionality is explicitly marked as such
> > > by its presence in mm/vma.h.
> > >
> > > It also places the header includes required by vma.c in vma_internal.h,
> > > which is simply imported by vma.c. This makes the VMA functionality
> > > testable, as userland testing code can simply stub out functionality
> > > as required.
> >
> > My initial thought on vma_internal.h would be to contain the number of
> > 'helper' functions and internal structures while mm/vma.h would have the
> > interface.
> 
> This is what I've done though?
> 

Yes, for the most part.  I was just surprised to see all the #includes
move.  It makes sense though as it saves a huge number of stubs/#define
of header guards.

...

Thanks,
Liam




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux