[Top] [All Lists]

[RFC] xfsprogs: libxfs update to current kernel code

To: xfs@xxxxxxxxxxx
Subject: [RFC] xfsprogs: libxfs update to current kernel code
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 10 Dec 2014 10:41:22 +1100
Delivered-to: xfs@xxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
Hi folks,

I just pushed a libxfs-3.19-update branch to 


That contains an update of the libxfs code to match the current
kernel libxfs code. It's in pretty rough shape right now, but it
seems to work. It will get rebased as I refine the patchset.

The stages of the update are:

        - rework some libxfs definitions
        - update to 3.16 code
        - introduce libxfs error negation patches
        - restructure libxfs to match kernel code
        - update to the current for-next branch

In doing this update, there are a few things that need to be
separated out to the head of the series and made explicit:

        - support for anything pre- dir V2 goes away, so there's a
          bunch of new "use and older xfsprogs" conditions that need
          to be added and a significant amount of "handle old bugs"
          code that needs to go away
        - the equivalent kernel code only supports v2 inodes - it
          unconditionally sets the NLINK feature bit and converts v1
          inodes to v2 inodes. All the userspace tools need to be
          updated to match - they'll read v1 inodes, but they'll
          unconditionally set NLINK and write only v2 inodes.
        - the SHARED superblock stuff goes away, so killing that
          needs to be a standalone patch

Given these changes in supported functionality, I expect the first
release with this update to be a 3.3.0 release, not a 3.2.x release.
This probably makes it a good time to update mkfs default behaviour
as well (i.e. to default to CRC enabled filesystems).

There is also more cleanup work to be done after the 3.19 update:

        - the include file structure is somewhat cludgy. I simply
          made the new libxfs structure link into the existing
          include/xfs structure in a slightly different way, but
          this needs substantial rework to clean it up.
        - there is a convoluted mess of include files between
          include/ and libxfs/ that determine what code gets
          compiled and how it is seen externally. The first commit
          in the series sort of points out how messy this is, but
          this really needs to be better sorted to separate internal
          and externally visible libxfs functions, as well as
          separate libxfs structures from userspace structures like
          struct xfs_mount....

I don't really expect significant *code* review of the libxfs part
of the update - it's pretty large at at +7000/-6500 lines. I'm more
interested in getting feedback on the changes of supported
functionality and the infrastructure changes.  If anyone wants to
kick the tyres they are more than welcome to - at this stage any
feedback is better than none. :)


Dave Chinner

Attachment: signature.asc
Description: Digital signature

<Prev in Thread] Current Thread [Next in Thread>