From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D296C1FF1B4 for ; Tue, 15 Jul 2025 14:35:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752590108; cv=none; b=s787Dfm+5JBcxFECc7FdNGFDDwXwwRBWDdazhqF8A1swzWXCaQFfNPtl4pXrA2jYJpsK1Evs1RABB+SL2BDtFBOU4hBAOPQpNL1rsNGwC14IEI4zTyxVzPfyTbRRHEBnakjmeIFskyQImXQaEG0Pxjv4Db5iYWFT8KEcplm9Bjw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752590108; c=relaxed/simple; bh=r8tO1lOalXIKlyB59d5zfTu26CljhqrlTCDYWnWvHT0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=p3bI1i6OxYtPPnzFHTIcjE406FrtjMKxVTFYO/w4QoPg9YOcu0HGJoUHJrAG0qLafHtB207xgzV16IuWdLpGO+sFp6DTAiMZ8BUBuM/AmmodXoL5YR7DY7w7H+EyWTcUe01gQWVyG8wV/Vs+b1C2m/3Q5hHvSk03W0YH/DOamtE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0CC7E1DA533; Tue, 15 Jul 2025 14:34:58 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf10.hostedemail.com (Postfix) with ESMTPA id 049A02F; Tue, 15 Jul 2025 14:34:53 +0000 (UTC) Date: Tue, 15 Jul 2025 10:34:54 -0400 From: Steven Rostedt To: Greg KH Cc: Christoph Hellwig , Mathieu Desnoyers , linux-kernel@vger.kernel.org, Josh Poimboeuf , Masami Hiramatsu , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Jens Remus , Linus Torvalds , Andrew Morton , tech-board-discuss@lists.linuxfoundation.org Subject: Re: [RFC PATCH 2/5] unwind: Export unwind_user symbol to GPL modules Message-ID: <20250715103454.4e39917e@batman.local.home> In-Reply-To: <2025071127-reunion-residence-c0f2@gregkh> References: <20250709212556.32777-1-mathieu.desnoyers@efficios.com> <20250709212556.32777-3-mathieu.desnoyers@efficios.com> <20250711065742.00d6668b@gandalf.local.home> <2025071124-cola-slouching-9dd2@gregkh> <20250711091734.5632dcf7@gandalf.local.home> <2025071127-reunion-residence-c0f2@gregkh> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 7r1wypx6u15xy6nwgza64uhszqs7t6io X-Rspamd-Server: rspamout08 X-Rspamd-Queue-Id: 049A02F X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1+pHj7bZiAQuLDelWHdZkjBNreBonh4slc= X-HE-Tag: 1752590093-610028 X-HE-Meta: U2FsdGVkX1+i/41KjCGp238kOK1HiTcFgjBDM+CUrYwUFBZMZEtEU6aL2RgiDFzTQGYqW563Grd/2LRQfqF082ls3nSYu26iN2o0uwqNilILVjuq+6fmPfbuOX4ScNdjRkONjCCGMxOsJciFK/zm2HbWI3qdBP5PUd/dnQRWiKQZJWAcApIilQ1yvcw/WJbOewSd3NxojGKPgFk8GbUGS9JT6FY3RhfVJJMkkVUw23Iy1L+XteRcNmSn3CSJgf/t/aipw6B+fBIc6qUCUP3xro46taMc/uhw28nqamHhMbaxruXewHfeptAHIruvR86fBYW9jS1GOHLzG6XhFtnQ1DxXhtxG6iUCnzWE2wc+FxxRqRdOVxDoNIMkIvaC+AbUCByL2qZBky2EbfK81qnrCQ== On Fri, 11 Jul 2025 18:39:40 +0200 Greg KH wrote: > I'll show one real-world example, the USB offload path code, that you > are using today on your Android phones that saves loads of battery life. > In older kernels, the hooks/exports needed for that were all over the > place, it took an engineer years to get this all working for lots of > different hardware types and merged upstream properly. They knew that > they could not just get the upstream developers to export the needed > functions, they had to get their working code merged in order to be able > to have it happen. And they did! So how did this work? Did they write infrastructure in the core kernel code with EXPORT_SYMBOL_GPL() to that this new functionality could be used by other USB drivers? In doing that, the work is adding functionality to all users inside the kernel as well as to out of tree modules. When I said that tracers are different, it comes down to that the in-tree tracers are never a module. Any new infrastructure they use will not be exported. There's no way that LTTng can add infrastructure for perf and ftrace and then use it. So how is it suppose to work to integrate with the kernel if we do not allow it to access the shared infrastructure? If perf and ftrace were modules, there would likely be a lot of infrastructure functions with EXPORT_SYMBOL_GPL() that LTTng could use and work to change its infrastructure to use the same infrastructure as perf and ftrace. But because perf and ftrace are never a module, there's no way for LTTng to work with the same code. I explain this in more detail with my reply to Linus in the other thread that you were Cc'd on. https://lore.kernel.org/all/20250715052459.0000e119@gandalf.local.home/ -- Steve