[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160321175235.GA5812@birch.djwong.org>
Date: Mon, 21 Mar 2016 10:52:35 -0700
From: "Darrick J. Wong" <darrick.wong@...cle.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: axboe@...nel.dk, torvalds@...ux-foundation.org,
bfields@...ldses.org, tytso@....edu, martin.petersen@...cle.com,
linux-api@...r.kernel.org, david@...morbit.com,
linux-kernel@...r.kernel.org, shane.seymour@....com,
linux-fsdevel@...r.kernel.org, jlayton@...chiereds.net,
akpm@...ux-foundation.org
Subject: Re: [PATCH 3/3] block: implement (some of) fallocate for block
devices
On Mon, Mar 21, 2016 at 08:38:27AM -0700, Christoph Hellwig wrote:
> On Tue, Mar 15, 2016 at 12:42:44PM -0700, Darrick J. Wong wrote:
> > #include <linux/cleancache.h>
> > #include <linux/dax.h>
> > #include <asm/uaccess.h>
> > +#include <linux/falloc.h>
>
> Maybe keep this before asm/uaccess.h
>
> > +long blkdev_fallocate(struct file *file, int mode, loff_t start, loff_t len)
>
> should be marked static.
Ok (to both).
>
> > + /* We haven't a primitive for "ensure space exists" right now. */
> > + if (!(mode & ~FALLOC_FL_KEEP_SIZE))
> > + return -EOPNOTSUPP;
>
> I don't really understand the comment. But I think you'd be much
I don't know of a block device primitive that corresponds to the "default"
mode of fallocate, as documented in the manpage (i.e. mode == 0). I agree
that the whole thing could be simplified in the manner you point out below.
> better off with having blkdev_fallocate as just a tiny wrapper that has
> a switch for the supported modes, e.g.
>
> switch (mode) {
> case FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE:
> return blkdev_punch_hole();
> case FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE::
> return blkdev_zero_range();
> default:
> return -EOPNOTSUPP;
> }
>
> > +EXPORT_SYMBOL_GPL(blkdev_fallocate);
>
> and no need to export it either..
Ok.
--D
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists