From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755371AbbE2Ahh (ORCPT ); Thu, 28 May 2015 20:37:37 -0400 Received: from mail-vn0-f46.google.com ([209.85.216.46]:43012 "EHLO mail-vn0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755292AbbE2Ahb convert rfc822-to-8bit (ORCPT ); Thu, 28 May 2015 20:37:31 -0400 MIME-Version: 1.0 In-Reply-To: References: <9fee05c37be52b8f8fcd5df05f391af9e3d820e8.1429868795.git.agruenba@redhat.com> Date: Thu, 28 May 2015 20:37:30 -0400 Message-ID: Subject: Re: [RFC v3 37/45] nfs/sunrpc: No more encode and decode function pointer casting From: Trond Myklebust To: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= Cc: Linux Kernel Mailing List , Linux FS-devel Mailing List , Linux NFS Mailing List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2015 at 7:40 PM, Andreas Grünbacher wrote: > 2015-05-29 1:11 GMT+02:00 Trond Myklebust : >> How is this even remotely relevant to ACL functionality, and why does >> it deserve to bypass the NFS tree? > > I've posted this to the linux-nfs mailing list for review among > others, how is that > bypassing the NFS tree? Would you prefer those things sent to you personally > as well? No. I'm saying that changes that affect the core RPC code should not be going through external trees as part of an external feature; they should go through the maintainer trees. > This patch prepares for for the next one which changes the prototype > of the encode > functions to return an error code. Without this patch, oversights in > the next patch > would go unnoticed; with this patch, the compiler will complain. > See the comments to that patch too. There are precedents for doing what you are trying to accomplish, and they do not require changes to core code. Trond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [RFC v3 37/45] nfs/sunrpc: No more encode and decode function pointer casting Date: Thu, 28 May 2015 20:37:30 -0400 Message-ID: References: <9fee05c37be52b8f8fcd5df05f391af9e3d820e8.1429868795.git.agruenba@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linux Kernel Mailing List , Linux FS-devel Mailing List , Linux NFS Mailing List To: =?UTF-8?Q?Andreas_Gr=C3=BCnbacher?= Return-path: In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Thu, May 28, 2015 at 7:40 PM, Andreas Gr=C3=BCnbacher wrote: > 2015-05-29 1:11 GMT+02:00 Trond Myklebust : >> How is this even remotely relevant to ACL functionality, and why doe= s >> it deserve to bypass the NFS tree? > > I've posted this to the linux-nfs mailing list for review among > others, how is that > bypassing the NFS tree? Would you prefer those things sent to you per= sonally > as well? No. I'm saying that changes that affect the core RPC code should not be going through external trees as part of an external feature; they should go through the maintainer trees. > This patch prepares for for the next one which changes the prototype > of the encode > functions to return an error code. Without this patch, oversights in > the next patch > would go unnoticed; with this patch, the compiler will complain. > See the comments to that patch too. There are precedents for doing what you are trying to accomplish, and they do not require changes to core code. Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html