Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751674AbcLEOtQ (ORCPT ); Mon, 5 Dec 2016 09:49:16 -0500 Received: from mail-oi0-f66.google.com ([209.85.218.66]:33322 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751064AbcLEOtO (ORCPT ); Mon, 5 Dec 2016 09:49:14 -0500 MIME-Version: 1.0 X-Originating-IP: [217.173.44.24] In-Reply-To: <20161204173317.GH1555@ZenIV.linux.org.uk> References: <147986254484.19139.8038609825799670925.stgit@warthog.procyon.org.uk> <147986255194.19139.9583434946564699577.stgit@warthog.procyon.org.uk> <20161204043803.GA1022@ZenIV.linux.org.uk> <20161204173317.GH1555@ZenIV.linux.org.uk> From: Miklos Szeredi Date: Mon, 5 Dec 2016 15:49:12 +0100 Message-ID: Subject: Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available [ver #3] To: Al Viro Cc: David Howells , linux-fsdevel@vger.kernel.org, Linux API , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1199 Lines: 24 On Sun, Dec 4, 2016 at 6:33 PM, Al Viro wrote: > On Sun, Dec 04, 2016 at 04:38:05AM +0000, Al Viro wrote: > >> I understand wanting to avoid extra arguments, but you are asking for trouble >> with that sort of calling conventions. Verifying that all call chains have >> these fields initialized is bloody unpleasant and it *is* going to break, >> especially since the rules are "you need to initialize it for vfs_xgetattr(), >> but not for vfs_getattr()" - the names are similar enough for confusion, >> and that's not the only such pair. > > FWIW, there's a bit of abuse of struct kstat in overlayfs object > creation paths - for one thing, it ends up with a very small subset > of struct kstat (mode + rdev), for another it also needs link in > case of symlinks and ends up passing it separately. > > IMO it would be better to introduce a separate object for that; does anybody > have objections to something like the patch below? In principle, we might > even lift that thing into general API and switch ->mkdir()/->mknod()/->symlink() > to identical calling conventions. Hell knows, perhaps ->create() as well... > Comments? Good cleanup. Applied, thanks. Miklos