From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8B543233958 for ; Fri, 19 Jun 2026 20:28:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781900906; cv=none; b=AAI4azsFlQmtWE5NwiFCdmN8igioXlLf8T4eehoXbNoR9nByx+4l23dOeR1W1fdE9vin9R9YQCuz6YcmHpjuMSsKJcmst/lryUCOJOzlXb9azWXnaRih7Uedbaadqyi4DIluE/L9m8G4Y2be7y9SOv5ULKPbKPchWYrhLCYk4Bw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781900906; c=relaxed/simple; bh=k5mbIbZ7M6Fj79XTRBsA1bt6r1NUgyDMO7CwK80Yv6Y=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IZnrSKIwDxP45n8rmHf7f3SBILUSheUhFosvmUQEWCLFD1YbC6ppNOwL5esGkX4Tl4lrnvxZ9USFi1/bdWEuQM3e/bj0jYZZ/XDH7fUcpVB+qknWBe+QoDv4LvelWXwsgg1OGFz9yO4H0hgbZ9xfTNb6Oy5V4WTqWL3uXa4qLDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WR2N0z0Y; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WR2N0z0Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BD891F000E9; Fri, 19 Jun 2026 20:28:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781900905; bh=8Pxf2fM4tVZI9aBPt3jkhC3lp8zhYpGzsxCNx5iUAAA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=WR2N0z0YOC91nabMI3C1xwnpLz4MuLdRUbmwQDPqe6rcVv5eFuTt2bEVr+k5/oIvN 0pjWLs51OTl5YTQsukP1oqfmeojpgORlwRf3I9hgriU9gPsOji1ktr+2vwGV4xai42 +XNaYLCxQj6uAP9e76crw6VChxl3IMEtNXLvgLuWMkPzEr8UzgwogV+t2VSurWPwIO rhoE4UXbZ6Vg0U4drgepoOOFrArQ82jENeat+kkEJ+PoDQpWxuyeF7ZSLRW1HBBaG6 FooTncetj3MYINc0+IU33jlxOvdv1/q26hn4/YL/B7B9ZPfn1O0mFEnQJeWcSxQtdn 7KAbcNyNbWYlA== From: Thomas Gleixner To: Linus Torvalds , Sebastian Andrzej Siewior Cc: John Ogness , Peter Zijlstra , Steven Rostedt , Yury Norov , LKML , Masami Hiramatsu , Mathieu Desnoyers , Ao Sun , David Carlier , Karl Mehltretter , Martin Kaiser , Pengpeng Hou , Qian-Yu Lin , Rik van Riel , Rosen Penev , Shuvam Pandey , Vineeth Pillai , Yash Suthar , Yu Peng Subject: Re: [GIT PULL] tracing: Updates for 7.2 In-Reply-To: References: <20260616180122.57a3b426@fedora> <20260619081513.3e4a1fb0@fedora> <20260619154025.h4BHc5wi@linutronix.de> <20260619183030.Hhxw5N5G@linutronix.de> Date: Fri, 19 Jun 2026 22:28:22 +0200 Message-ID: <87tsqyb7h5.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Jun 19 2026 at 12:07, Linus Torvalds wrote: > On Fri, 19 Jun 2026 at 11:30, Sebastian Andrzej Siewior > wrote: > But in general, if the question is "should we split this header file > up if it's straightforward and easy", the answer is *ALWAYS* a > resounding "YES". Full ACK. > Most of the time it's just a pain to unravel all the type > dependencies. This case look strivial compared to some we've done. > > One of the things I at one point hoped sparse would do was a "you're > including this header for no good reason" tooling. > > But it's non-trivial to do, particularly with lots of different > architectures that aren't very consistent in where they declare or use > things. That's only one part of the overall problem. People are really careless when they add new things. It took me literally weeks to handle all the 0-day compile fallout when I tried to disentangle the __percpu mess so that a header using a __percpu annotation in a struct declaration is not required to include the world and running into recursive header hell. See c06cd66387da ("percpu: Sanitize __percpu_qual include hell") I'm still fighting to resolve the last remaining issue to get rid of the asm/xtime.h dependency in some other cleanup project. That header is so deeply ingrained in some of our header chains for the very wrong reasons. I've tried to utilize AI for analyzing it, but that ended up in an even bigger disaster. One thing I'm seeing is that the kernel is patently bad in separating data type declarations from actual APIs, where the APIs usually just need a forward declaration of the pointer type. Ditto for struct declarations with pointer types. After doing quite some of these disentanglements manually and trying to utilize all kinds of tooling, I still have no good answer to this unfortunately. Thanks, tglx