[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Aug 2023 11:17:49 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Rasmus Villemoes' <linux@...musvillemoes.dk>,
Petr Mladek <pmladek@...e.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC: Marco Elver <elver@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Alexander Potapenko <glider@...gle.com>,
"Dmitry Vyukov" <dvyukov@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: RE: [PATCH v2 2/3] lib/vsprintf: Split out sprintf() and friends
From: Rasmus Villemoes
> Sent: 07 August 2023 20:32
...
> No, please. Let's have a separate header for the functions defined in
> vsprintf.c. We really need to trim our headers down to something more
> manageable, and stop including everything from everywhere just because
> $this little macro needs $that little inline function.
The problem I see isn't things like kernel.h defining a few 'library'
functions, but deep nested includes that means that pretty much all
of the headers get pulled into all the compiles.
Some nested includes sequences can go through an "asm" header
that you might expect to be architecture specific stuff and then
include something like ioctl.h.
Add something like #define IO_WR @@@ to the top a C file
and then see where the compiler finds the duplicate definition.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists