[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <83824aca89a148bd861e8eccef54bf44@AcuMS.aculab.com>
Date: Tue, 15 Aug 2023 09:58:54 +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: 10 August 2023 10:09
...
> We really have to stop pretending it's ok to rely on header a.h
> automatically pulling in b.h, if a .c file actually uses something
> declared in b.h. [Of course, the reality is more complicated; e.g. we
> have many cases where one must include linux/foo.h, not asm/foo.h, but
> the actual declarations are in the appropriate arch-specific file.
> However, we should not rely on linux/bar.h pulling in linux/foo.h.]
IMHO (for what it matters) it would be better to focus on why
#include <cdev.h> pulls in around 350 other headers (look at
a .d file) that worry about moving a few files into a new
'leaf' header from somewhere that pretty much everything has
to include anyway.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists