Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4934504pxb; Tue, 5 Oct 2021 13:40:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVf+Qhdoupjf18SDZ3IrwQX+JLbos7qQKbM02Dw1jzPPm3XBAzmDhipwJZJkQ2LS20AP8b X-Received: by 2002:a17:902:9303:b029:12c:29c:43f9 with SMTP id bc3-20020a1709029303b029012c029c43f9mr7239305plb.5.1633466418280; Tue, 05 Oct 2021 13:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633466418; cv=none; d=google.com; s=arc-20160816; b=Y8HuoRjEhzEXoyRa2DcZvaDIVwy9NroOEWRk3lPmNITJF/5KcqSKrigFt/8L/CYX9W zTJcfYjr8xztj+m17afXFSk+/vO739K0SFdJCBTV0JXecQswaTJ5r3NB4e48nB8QuAzg i2NxGQUp9+Gwjg82R1KMiQ5usH/TpRl2j+0ziQS+5YCMtlibyb+qgKlQqNQc6d7dHjf2 ll5sqEuA27kS6WSJ5dXSsKXMyBpFgh2U9+YfmPkOtuQt2JXoDrhC0zn1x1mYOHjAW/aN CxIsAJDBW27eBcXgovCRxnUvr+oNDDlRRFSKlSYUfUh6Vo9KsGRwD7ukhuy92eDfa52/ R1Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=J1dK+9M0Zwcb9VrC7OQjr5R7pj7XnnKQLFMw7gNJp2M=; b=bioMeVbHwj7fLgvRx1a4AVkv1OCaODOdywbsf07vacWZSs+jEvriw1v/jvAZnXyjCn FlEJFnzT8fr4M7pzIFWnParA00q07f9agvyXCH6WRxcPaAtVrFIjk0RaN3qpxxhmFj1v rdlLlUMZk/v7ciU0zFk+ozhzoAwKcqAMe/AkaHR2Rh96a5LZb6l6F97fQc+oZa430u4/ hsPIk7h81sh0WivNcCZr0D9uh6jQFG3TveryBvmCTd2DhvgWwuBZm8MOsCUqgnTnBxkn swCQlu33sIrYrrSN2h4f/lXt6p44TEGTjTlHQc59boswTU3hImjyrfyqyCJx6W4PdhGN q82g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cp16si21373335plb.461.2021.10.05.13.40.03; Tue, 05 Oct 2021 13:40:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236525AbhJEUju (ORCPT + 99 others); Tue, 5 Oct 2021 16:39:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:54998 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230098AbhJEUjt (ORCPT ); Tue, 5 Oct 2021 16:39:49 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5065C613D5; Tue, 5 Oct 2021 20:37:57 +0000 (UTC) Date: Tue, 5 Oct 2021 16:37:54 -0400 From: Steven Rostedt To: Jan Engelhardt Cc: Mathieu Desnoyers , Rasmus Villemoes , linux-kernel , Linus Torvalds , Paul , Josh Triplett , Lai Jiangshan , "Joel Fernandes, Google" , Pablo Neira Ayuso , Jozsef Kadlecsik , Florian Westphal , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , rcu , netfilter-devel , coreteam , netdev Subject: Re: [RFC][PATCH] rcu: Use typeof(p) instead of typeof(*p) * Message-ID: <20211005163754.66552fb3@gandalf.local.home> In-Reply-To: <20211005154029.46f9c596@gandalf.local.home> References: <20211005094728.203ecef2@gandalf.local.home> <639278914.2878.1633457192964.JavaMail.zimbra@efficios.com> <826o327o-3r46-3oop-r430-8qr0ssp537o3@vanv.qr> <20211005144002.34008ea0@gandalf.local.home> <20211005154029.46f9c596@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 5 Oct 2021 15:40:29 -0400 Steven Rostedt wrote: > struct trace_pid_list { > unsigned long ignore; > }; > > Rename the above struct trace_pid_list to struct trace_pid_internal. > > And internally have: > > union trace_pid_data { > struct trace_pid_list external; > struct trace_pid_internal internal; > }; > > Then use the internal version within the C file that modifies it, and just > return a pointer to the external part. So this has proved to be a PITA. > > That should follow the "C standard". Really, thinking about abstraction, I don't believe there's anything wrong with returning a pointer of one type, and then typecasting it to a pointer of another type. Is there? As long as whoever uses the returned type does nothing with it. That is, if I simply do: In the header file: struct trace_pid_list { void *ignore; }; struct trace_pid_list *trace_pid_list_alloc(void); void trace_pid_list_free(struct trace_pid_list *pid_list); And then in the C file: struct pid_list { [...] }; struct trace_pid_list *trace_pid_list_alloc(void) { struct pid_list *pid_list; pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL); [..] return (struct trace_pid_list *)pid_list; } void trace_pid_list_free(struct trace_pid_list *list) { struct pid_list *pid_list = (struct pid_list *)list; [..] kfree(pid_list); } That should be perfectly fine for standard C. Right? -- Steve