[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNEHt564a8RCLWon@alley>
Date: Mon, 7 Aug 2023 17:03:19 +0200
From: Petr Mladek <pmladek@...e.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Marco Elver <elver@...gle.com>, linux-kernel@...r.kernel.org,
kasan-dev@...glegroups.com, linux-mm@...ck.org,
Steven Rostedt <rostedt@...dmis.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
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
On Sat 2023-08-05 20:50:26, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> sprintf() and friends are used in many drivers without need of the full
> kernel.h dependency train with it.
>
> Here is the attempt on cleaning it up by splitting out sprintf() and
> friends.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
> include/linux/kernel.h | 30 +-----------------------------
> include/linux/sprintf.h | 25 +++++++++++++++++++++++++
> lib/test_printf.c | 1 +
> lib/vsprintf.c | 1 +
> 4 files changed, 28 insertions(+), 29 deletions(-)
> create mode 100644 include/linux/sprintf.h
I agree that kernel.h is not the right place. But are there any
numbers how much separate sprintf.h might safe?
Maybe, we should not reinvent the wheel and get inspired by
userspace.
sprintf() and friends are basic functions which most people know
from userspace. And it is pretty handy that the kernel variants
are are mostly compatible as well.
IMHO, it might be handful when they are also included similar way
as in userspace. From my POV printk.h is like stdio.h. And we already
have include/linux/stdarg.h where the v*print*() function might
fit nicely.
How does this sound, please?
Best Regards,
Petr
Powered by blists - more mailing lists