xfs
[Top] [All Lists]

Re: Is jdm_delete_filehandle part of a public API?

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Is jdm_delete_filehandle part of a public API?
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 4 Aug 2014 12:20:05 +1000
Cc: Eric Sandeen <sandeen@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140801135305.GA31894@xxxxxxxxxxxxx>
References: <53D7DA7F.2040706@xxxxxxxxxx> <20140801135305.GA31894@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Aug 01, 2014 at 06:53:05AM -0700, Christoph Hellwig wrote:
> Talking about libhandle: this one has been a bit bitrotted.  Maybe it's
> a good time to move everything over to the kernel by handle syscalls
> and deprecated it?

First you need to make the kernel by-handle interfaces handle the
sae functionality as the XFS by-handle ioctls.

        1. O_NOCMTIME doesn't exist, and so there's no way to do
           invisible IO on files.
        2. Can we construct VFs filehandles in userspace from
           bulkstat information (dump, xfs_fsr and others rely on
           this capability)?
        3. The kernel by-handle interfaces cannot manipulate
           attributes at all (i.e. attr-list, attr-multi
           functionality).

So until the VFS by-handle interfaces can do these things, we can't
change libhandle over to use the newer kernel interfaces.

I'm also pretty sure the incompatible handle format would mean
big problems if someone were to be storing file handles in userspace
and they upgrade their version of libhandle. i.e. such a library
implementation change is not forwards or backwards compatible with
existing applications, but bumping the major shared library version
should solve that problem.

However, these are all solvable problems. It's definitely a low
priority for me to do this, but if you want to do it patches will
definitely be accepted ;)

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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