From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (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 BA6E71A267 for ; Sat, 20 Jun 2026 09:22:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781947368; cv=none; b=Jxsyd1/iErtX4J3bNGFduwzxdGlU2H6c3OR2dl93ZFqMvIvJX1kOfgM7A7ciRvJUlvVZBC9C1FJ6H/LjemTFFqu6lCNCO/EfTqm/vp9fyzau88WvW6FzRkIKc2B8ZplVNWRjmjmKPQZL2CTwf9I9C9pFodzexTPnFK9hnIsbCNU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781947368; c=relaxed/simple; bh=KKu+GYIjSQTveuWfjwq/rhA2ZUKBSARIsqV20sVrHgg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k4pTYRxYdVdT/liBgdmt5e7kG89uL794HEU7BUUPhWMnuDLgKDVsPaKk9v2R+B6wQBP0JoyLBdrFlLKjAJzWa+9JgGQV+PRsCrP3dSW+ozK2Wjd7pSCH5gvaGlt9Kb7cDiY440itOeePIvywVnxichE82lvRHPY/UQNtCVKXNWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=TJ8GzfR2; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="TJ8GzfR2" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1781947362; bh=0EStDibS/eoa2QB6imL2GwxC95f++Y73eQC9H8rN35c=; h=From:Message-ID:From; b=TJ8GzfR2cK4zZE6oe2gE9k6ncSQ1D62/OpUOR9tFvRaE7u8bHVFrctWPbrOIjGlLH W0NZoMS7fiW3bQE0cGERSP1Rj+JdwsOiBbLy2yQHtTTHXNgX2OGoXWh4Pr5Y26SC/z SMhIHjZRnFFYlU4Ij4eQaxlhxOrW2jwiiHFsuHJ4= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 401B6C0B35; Sat, 20 Jun 2026 11:22:42 +0200 (CEST) Date: Sat, 20 Jun 2026 11:22:39 +0200 From: Willy Tarreau To: Linus Torvalds Cc: Thomas Gleixner , Sebastian Andrzej Siewior , 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 Message-ID: References: <20260616180122.57a3b426@fedora> <20260619081513.3e4a1fb0@fedora> <20260619154025.h4BHc5wi@linutronix.de> <20260619183030.Hhxw5N5G@linutronix.de> <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; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jun 19, 2026 at 01:55:15PM -0700, Linus Torvalds wrote: > On Fri, 19 Jun 2026 at 13:28, Thomas Gleixner wrote: > > > > 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. > > We tend to do a lot of inline functions, and that often makes it > impossible to do the simple "just forward-declare the type". > > And often there are fairly good reasons for the inline functions, in > that they tend to be much safer than macros, both for type checking > and for the whole "use argument once" reason (they also avoid compiler > warnings when the argument _isn't_ used). In haproxy we've had a hard time dealing with circular dependencies and build time issue for a while and a few years ago we found what looks like a mostly optimal arrangement. Each include file exists in two versions: - one suffixed with "-t" which contains only type declarations (#define as well as enums, structs etc) - the main one without "-t" that includes the first one and contains declarations (extern variables & functions as well as inline) And all this with a strict rule: no -t file may ever include any of the other ones. It now works pretty well, and we could significantly reduce the depth of includes and no longer need to resolve broken inline-to-inline references. And we discovered that many C files don't even need the main file and only need types definitions, further reducing build time. Also we figured that certain -t files only included another one for a single struct definition that appeared as a pointer, so these were sometimes replaced with just a forward-declaration before use and that was done. We made mistakes too, most of our macros that replaced inline functions tend to be in the main files instead of the -t one as the rule implies, encouraging to place further macro definitions at the wrong place. But moving them is no big deal. If I would change something, it would probably be around long macro definitions (e.g. series of flags) that are often not needed by other -t files and only by functions. It's just difficult for me to express that distinction in a way that's clear enough for eveyrone to respect, but this could definitely further reduce the preprocessing time of the types-only "-t" files. Willy