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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 C0EA2CA9EAF for ; Thu, 24 Oct 2019 04:57:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91E5E2166E for ; Thu, 24 Oct 2019 04:57:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="f+iU1lVJ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2408361AbfJXE5Q (ORCPT ); Thu, 24 Oct 2019 00:57:16 -0400 Received: from mail-yw1-f68.google.com ([209.85.161.68]:41658 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725298AbfJXE5Q (ORCPT ); Thu, 24 Oct 2019 00:57:16 -0400 Received: by mail-yw1-f68.google.com with SMTP id o195so3404768ywd.8; Wed, 23 Oct 2019 21:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qp4ylpFjT2NK5D3YlCPCDZfnUsSpfLeB6JcWlmTT8JE=; b=f+iU1lVJ+8MXE0YjXhbzT4Z+QZTKEVbpSj7I64WEMcxAgcUOKckEALuDnxjfop1KDz /GEuxtdqM/gAmg/8rUQcbM54P8ZvUqXo23LCox8OZKBVBlVoDn1p5gmEXxfQnAWBfBHW uZZaGVOWsT//cwHGlbqENLvAYitmYf5NxnxRGYapcBJVSV1rP+NlFCXZHqVZ6fsYCVwo HiL1fAZTVAeLbnNXS5YnMp44jrRgVnpRxhkGyVWlHqmqFFsCMZbuTBKjna3CheOTh8v8 hD6hfXAtyLGGlQqfHMdlsFiQ1XgpXWIL5nune/Pgn/JF3P1WqL13u+LVKHRsnQpi/3uP Pzow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qp4ylpFjT2NK5D3YlCPCDZfnUsSpfLeB6JcWlmTT8JE=; b=t2MGTIc8mTc7xW5/p/CK16Ve9OEKmiR3Bt1eoB5Z7AoMwDnIldppJFs4AQlRg5rSTa q12+rvFQWnsBdLRSERRYnp2UD56h9Ed7dygSLlsN0K+KpagF9fNJEIyKLAZLanO3WOPf xM/lf7xUbla/jk3vlTj9s1KC4BPrPrpH5tFKq9eB/9V+W/lhbBMXJOZIyvrB5aDeJJ6t C+eN3/HhTt2oLPFy4NmgSsOa9Izgi1LmAXlmxlOybOx4Ju3ogFv6LeWPgiB0NsBh1iZd fM7e68NeYec1KF3EY1ABYuene9koRVfxcXINUYEd59XIU70IQZHgjxsu/Ak2dZoAh9dB jjbg== X-Gm-Message-State: APjAAAX2taqOZp6Wh4uI+eNoiHVcayhSQURKPdVWJQhiiAase5zce9Le cDp9IVjonZ/SxmlpoPcPLJDkSfLsNotmk4dR8To= X-Google-Smtp-Source: APXvYqzpUv8fnfcjV1KksbDdhWbx31x/A6CcO3wQjALxaBgCfUkMkcsChuqQOOuA9702g94fFIVsWA6cYWlyk5yi/8s= X-Received: by 2002:a81:6c58:: with SMTP id h85mr5010753ywc.88.1571893034732; Wed, 23 Oct 2019 21:57:14 -0700 (PDT) MIME-Version: 1.0 References: <20191022204453.97058-1-salyzyn@android.com> <20191022204453.97058-2-salyzyn@android.com> <8CE5B6E8-DCB7-4F0B-91C1-48030947F585@dilger.ca> In-Reply-To: <8CE5B6E8-DCB7-4F0B-91C1-48030947F585@dilger.ca> From: Amir Goldstein Date: Thu, 24 Oct 2019 07:57:03 +0300 Message-ID: Subject: Re: [PATCH v14 1/5] Add flags option to get xattr method paired to __vfs_getxattr To: Andreas Dilger Cc: Mark Salyzyn , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-doc@vger.kernel.org, CIFS , kernel-team@android.com, selinux@vger.kernel.org, Linux FS-devel Mailing List , Jonathan Corbet , Ext4 Developers List , Stephen Smalley , overlayfs , Andreas Gruenbacher , ecryptfs@vger.kernel.org, LSM List , Alexander Viro , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org [excessive CC list reduced] On Wed, Oct 23, 2019 at 11:07 AM Andreas Dilger via samba-technical wrote: > > > On Oct 22, 2019, at 2:44 PM, Mark Salyzyn wrote: > > > > Replace arguments for get and set xattr methods, and __vfs_getxattr > > and __vfs_setaxtr functions with a reference to the following now > > common argument structure: > > > > struct xattr_gs_args { > > struct dentry *dentry; > > struct inode *inode; > > const char *name; > > union { > > void *buffer; > > const void *value; > > }; > > size_t size; > > int flags; > > }; > > > Mark, > > > > I do not see the first patch on fsdevel > > and I am confused from all the suggested APIs > > I recall Christoph's comment on v8 for not using xattr_gs_args > > and just adding flags to existing get() method. > > I agree to that comment. > > As already responded, third (?) patch version was like that, The problem is that because of the waaay too long CC list, most revisions of the patch and discussion were bounced from fsdevel, most emails I did not get and cannot find in archives, so the discussion around them is not productive. Please resend patch to fsdevel discarding the auto added CC list of all fs maintainers. > gregkh@ > said it passed the limit for number of arguments, is looking a bit silly Well, you just matched get() to set() args list, so this is not a strong argument IMO. > (my paraphrase), and that it should be passed as a structure. Two others > agreed. We gained because both set and get use the same structure after > this change (this allows a simplified read-modify-write cycle). That sounds like a nice benefit if this was user API, but are there any kernel users that intend to make use of that read-modify-write cycle? I don't think so. > > We will need a quorum on this, 3 (structure) to 2 (flag) now (but really > basically between Greg and Christoph?). Coding style issue: Add a flag, > or switch to a common xattr argument structure? > IIRC, Christoph was asking why the silly struct and not simply add flags (as did I). He probably did not see Greg's comments due to the list bounce issue. If I read your second hand description of Greg's reaction correctly, it doesn't sound so strong opinionated as well. Me, I can live with flags or struct - I don't care, but... Be prepared that if you are going ahead with struct you are going to suffer from bike shedding, which has already started and you will be instructed (just now) to also fix all the relevant and missing Documentation. If, on the other hand, you can get Greg and the rest to concede to adding flags arg and match get() arg list to set() arg list, you will have a much easier job and the patch line count, especially in fs code will be *much* smaller - just saying. Thanks, Amir.