From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 800EDC43387 for ; Mon, 14 Jan 2019 17:59:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 56847204EC for ; Mon, 14 Jan 2019 17:59:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726723AbfANR67 (ORCPT ); Mon, 14 Jan 2019 12:58:59 -0500 Received: from verein.lst.de ([213.95.11.211]:48078 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726643AbfANR67 (ORCPT ); Mon, 14 Jan 2019 12:58:59 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 79DA56FA7F; Mon, 14 Jan 2019 18:58:57 +0100 (CET) Date: Mon, 14 Jan 2019 18:58:57 +0100 From: Christoph Hellwig To: Andreas =?iso-8859-1?Q?Gr=FCnbacher?= Cc: Christoph Hellwig , Carlos Maiolino , Linux FS-devel Mailing List , Andreas Dilger , sandeen@redhat.com, Dave Chinner Subject: Re: [PATCH 00/10 V2] New ->fiemap infrastructure and ->bmap removal Message-ID: <20190114175857.GA8634@lst.de> References: <20181205091728.29903-1-cmaiolino@redhat.com> <20181207093429.t3zzkxmfc4wlt5ny@hades.usersys.redhat.com> <20190114165023.GB7187@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Mon, Jan 14, 2019 at 06:56:16PM +0100, Andreas Grünbacher wrote: > Yes, locking. The fiemap_fill_cb callback hack still makes the fiemap > interface much uglier though. So couldn't the existing iop be used to > fill a kernel buffer in a way similar to what functions like > kernel_readv do? That would at least avoid wrecking an existing > interface. There is no file system visible change at all, the callback happens all behind the back. We could do a less extensible union based version, but I see absolutely no upside in that. set_fs as in kernel_readv needs to go away, so no new users should be added.