From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([65.50.211.133]:33381 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751237AbdISPzf (ORCPT ); Tue, 19 Sep 2017 11:55:35 -0400 Date: Tue, 19 Sep 2017 08:55:28 -0700 From: Christoph Hellwig To: Theodore Ts'o Cc: Andreas Dilger , "Darrick J. Wong" , Lukas Czerner , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH 4/7] xfs: Implement fallocate query support mode Message-ID: <20170919155528.GA8907@infradead.org> References: <1505749947-26360-1-git-send-email-lczerner@redhat.com> <1505749947-26360-5-git-send-email-lczerner@redhat.com> <20170918204838.GW6540@magnolia> <7B6B7C4C-7FEB-401F-B4EE-6E11E95FB246@dilger.ca> <20170919145520.c4y4w32lmsnqhhxp@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170919145520.c4y4w32lmsnqhhxp@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Sep 19, 2017 at 10:55:20AM -0400, Theodore Ts'o wrote: > Maybe the right answer is we should define a new pathconfat(2) system > call which can be used as part of a C library's implementation of > pathconf() and fpathconf()? glibc probably won't use it for years, of > course. But we can at least provide the information via an interface > which we can control, and which is capable of returning correct > results? glibc is very fast at picking up new kernel interface these days as long as they aren't too controversial. Implementing a syscall that backs a function they implement should not be in the controversial category I think.