* Re: File system robustness
From: Alan C. Assis @ 2023-07-18 13:04 UTC (permalink / raw)
To: Bjørn Forsman
Cc: Kai Tomerius, linux-embedded, Ext4 Developers List, dm-devel
In-Reply-To: <CAEYzJUGC8Yj1dQGsLADT+pB-mkac0TAC-typAORtX7SQ1kVt+g@mail.gmail.com>
Hi Bjørn,
On 7/18/23, Bjørn Forsman <bjorn.forsman@gmail.com> wrote:
> On Tue, 18 Jul 2023 at 08:03, Kai Tomerius <kai@tomerius.de> wrote:
>> I should have mentioned that I'll have a large NAND flash, so ext4
>> might still be the file system of choice. The other ones you mentioned
>> are interesting to consider, but seem to be more fitting for a smaller
>> NOR flash.
>
> If you mean raw NAND flash I would think UBIFS is still the way to go?
> (It's been several years since I was into embedded Linux systems.)
>
> https://elinux.org/images/0/02/Filesystem_Considerations_for_Embedded_Devices.pdf
> is focused on eMMC/SD Cards, which have built-in controllers that
> enable them to present a block device interface, which is very unlike
> what raw NAND devices have.
>
> Please see https://www.kernel.org/doc/html/latest/filesystems/ubifs.html
> for more info.
>
You are right, for NAND there is an old (but gold) presentation here:
https://elinux.org/images/7/7e/ELC2009-FlashFS-Toshiba.pdf
UBIFS and YAFFS2 are the way to go.
But please note that YAFFS2 needs license payment for commercial
application (something that I only discovered recently when Xiaomi
integrated it into NuttX mainline, bad surprise).
BR,
Alan
^ permalink raw reply
* Re: File system robustness
From: Alan C. Assis @ 2023-07-18 12:56 UTC (permalink / raw)
To: Kai Tomerius; +Cc: linux-embedded, Ext4 Developers List, dm-devel
In-Reply-To: <20230718053017.GB6042@tomerius.de>
Hi Kai,
I never used that, but please take a look at F2FS too.
BR,
Alan
On 7/18/23, Kai Tomerius <kai@tomerius.de> wrote:
> Hi Alan,
>
> thx a lot.
>
> I should have mentioned that I'll have a large NAND flash, so ext4
> might still be the file system of choice. The other ones you mentioned
> are interesting to consider, but seem to be more fitting for a smaller
> NOR flash.
>
> Regards
> Kai
>
>
>
> On Mon, Jul 17, 2023 at 10:50:50AM -0300, Alan C. Assis wrote:
>> Hi Kai,
>>
>> On 7/17/23, Kai Tomerius <kai@tomerius.de> wrote:
>> > Hi,
>> >
>> > let's suppose an embedded system with a read-only squashfs root file
>> > system, and a writable ext4 data partition with data=journal.
>> > Furthermore, the data partition shall be protected with dm-integrity.
>> >
>> > Normally, I'd umount the data partition while shutting down the
>> > system. There might be cases though where power is cut. In such a
>> > case, there'll be ext4 recoveries, which is ok.
>> >
>> > How robust would such a setup be? Are there chances that the ext4
>> > requires a fsck? What might happen if fsck is not run, ever? Is there
>> > a chance that the data partition can't be mounted at all? How often
>> > might that happen?
>> >
>>
>> Please take a look at this document:
>>
>> https://elinux.org/images/0/02/Filesystem_Considerations_for_Embedded_Devices.pdf
>>
>> In general EXT4 is fine, but it has some limitation, more info here:
>> https://opensource.com/article/18/4/ext4-filesystem
>>
>> I think Linux users suffer from the same problem we have with NuttX (a
>> Linux-like RTOS): which FS to use?
>>
>> So for deep embedded systems running NuttX I follow this logic:
>>
>> I need better performance and wear leveling, but I don't need to worry
>> about power loss: I choose SmartFS
>>
>> I need good performance, wear leveling and some power loss protection:
>> SPIFFS
>>
>> I need good performance, wear leveling and good protection for
>> frequent power loss: LittleFS
>>
>> In a NuttShell: There is no FS that 100% meets all user needs, select
>> the FS that meets your core needs and do lots of field testing to
>> confirm it works as expected.
>>
>> BR,
>>
>> Alan
>
^ permalink raw reply
* Re: File system robustness
From: Geert Uytterhoeven @ 2023-07-17 9:08 UTC (permalink / raw)
To: Kai Tomerius; +Cc: linux-embedded, Ext4 Developers List, dm-devel
In-Reply-To: <20230717075035.GA9549@tomerius.de>
CC linux-ext4, dm-devel
On Mon, Jul 17, 2023 at 10:13 AM Kai Tomerius <kai@tomerius.de> wrote:
>
> Hi,
>
> let's suppose an embedded system with a read-only squashfs root file
> system, and a writable ext4 data partition with data=journal.
> Furthermore, the data partition shall be protected with dm-integrity.
>
> Normally, I'd umount the data partition while shutting down the
> system. There might be cases though where power is cut. In such a
> case, there'll be ext4 recoveries, which is ok.
>
> How robust would such a setup be? Are there chances that the ext4
> requires a fsck? What might happen if fsck is not run, ever? Is there
> a chance that the data partition can't be mounted at all? How often
> might that happen?
>
> Thx
> regards
> Kai
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Florian Fainelli @ 2022-07-08 3:54 UTC (permalink / raw)
To: Uwe Kleine-König, linux-kernel, Paul Gortmaker,
David Woodhouse, linux-embedded, Herbert Xu, linux-crypto
Cc: kernel
In-Reply-To: <20210920080635.253826-1-u.kleine-koenig@pengutronix.de>
On 9/20/2021 1:06 AM, Uwe Kleine-König wrote:
> The mails I sent to Matt on September 14 and 20 both were refused by the
> MTA responsible for selenic.com (i.e. waste.org) with:
>
> 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete
>
> Also the most recent commit that involved him (ignoring "Cc: Matt
> Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS:
> Theodore Ts'o is taking over the random driver) where he was removed
> from the entry for random number drivers in 2012.
>
> So drop him completely from the list of maintainers.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This has not been applied and we still have entries in MAINTAINERS that
are bouncing for mpm@selenic.com, can we apply this patch?
--
Florian
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Greg KH @ 2021-10-24 9:57 UTC (permalink / raw)
To: Rob Landley
Cc: Tim.Bird, khilman, geert, laurent.pinchart, dwmw2, tbird20d,
u.kleine-koenig, linux-kernel, paul.gortmaker, linux-embedded,
herbert, linux-crypto, kernel, mporter, tglx, thomas.petazzoni
In-Reply-To: <f7c3aabd-8916-a0d2-7859-7088fab3114e@landley.net>
On Sun, Oct 24, 2021 at 02:24:48AM -0500, Rob Landley wrote:
> > The linux-embedded mailing list was created about the same time.
> > The thinking was that there are issues that transcend any particular
> > sub-system, directory, or file, such as boot time or system size or
> > real-time. Changes to keep these system-wide metrics in check might
> > need the assistance of a respected upstream maintainer, who could
> > guide developers working in these areas, or who could help keep
> > other kernel maintainers apprised of requirements in these areas
> > for embedded products.
>
> Greg KH wouldn't listen to me when I was Documention maintainer. He wouldn't
> listen when I was busybox maintainer. Maintainer-without-portfolio ain't gonna
> get him to start.
>
> Keep in mind Greg and Kay Sievers were joined at the hip until Linus threw Kay
> out of Linux dev and he bogged off to systemd. If you point out things like
> "sysfs should to present a stable API to userspace" or "it's a bad idea to
> depend on magic packages like udev or systemd as things every Linux system must
> not only use verbatim from a single upstream supplier but must replace every
> time they upgrade the kernel", Greg is reliably against them.
I love you Rob, but I have no idea how the creation of mdev has anything
to do with the topic at hand.
Best of luck!
greg k-h
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Rob Landley @ 2021-10-24 7:24 UTC (permalink / raw)
To: Tim.Bird, khilman, geert, laurent.pinchart
Cc: dwmw2, tbird20d, u.kleine-koenig, linux-kernel, paul.gortmaker,
linux-embedded, herbert, linux-crypto, kernel, mporter, tglx,
thomas.petazzoni
In-Reply-To: <BYAPR13MB250310153BF63EF3ED50F294FDBD9@BYAPR13MB2503.namprd13.prod.outlook.com>
On 10/19/21 5:54 PM, Tim.Bird@sony.com wrote:
> Well... Let me give some history, and then pontificate a little on the entry.
>
> Originally, this entry was created after Andrew Morton gave a talk at
> an early Embedded Linux Conference, saying that there should be some
> "ombudsman" for embedded issues in the kernel. This was in 2008.
I've been doing this sort of thing on and off for a while, but I admit to
gradually burning out over the years (sometime between
https://www.spinics.net/lists/linux-embedded/msg00148.html and
https://lkml.org/lkml/2017/9/13/651) as linux-kernel became actively hostile to
hobbyists.
> The linux-embedded mailing list was created about the same time.
> The thinking was that there are issues that transcend any particular
> sub-system, directory, or file, such as boot time or system size or
> real-time. Changes to keep these system-wide metrics in check might
> need the assistance of a respected upstream maintainer, who could
> guide developers working in these areas, or who could help keep
> other kernel maintainers apprised of requirements in these areas
> for embedded products.
Greg KH wouldn't listen to me when I was Documention maintainer. He wouldn't
listen when I was busybox maintainer. Maintainer-without-portfolio ain't gonna
get him to start.
Keep in mind Greg and Kay Sievers were joined at the hip until Linus threw Kay
out of Linux dev and he bogged off to systemd. If you point out things like
"sysfs should to present a stable API to userspace" or "it's a bad idea to
depend on magic packages like udev or systemd as things every Linux system must
not only use verbatim from a single upstream supplier but must replace every
time they upgrade the kernel", Greg is reliably against them.
> I would say that realtime has been shepherded pretty well by Thomas
> Gleixner (and it's almost all upstream!), independent of this entry.
> The other system-wide issues (boot time and system size), people
> have pretty much given up on,
Nah, I've gotten them trimmed/working acceptably well in my systems. I just
don't bother trying to poke linux-kernel about it anymore. Not since the Linux
Foundation chased hobbyists out of Linux to the point where people literally
started asking if hobbysts had ever really existed (circa
https://lwn.net/Articles/563578/).
Peter Anvin is actively hostile to the idea of reducing build-time dependencies
(http://lkml.iu.edu/hypermail/linux/kernel/0802.1/4400.html) to the point that
when my perl removal patches finally got traction in 2013 (after 5 years of
follow-through), he switched one of his perl scripts to use bc instead so things
like Gentoo and Linux From Scratch had to add a new build dependency for him
(neither was installing bc before). This was after I'd convinced Denys to make
ash do 64 bit math on 32 bit hosts so my shell translation ran under bash dash
and ash, and then when that was rejected rewrote it in C, and when Andrew Morton
went around him to take my patches THEN he piped up with a patch to keep the
build complex. Circa 2018 or so when they made kconfig turing complete (so make
oldconfig on a new kernel can "rm -rf ~" if it wants to) they added flex and
bison as dependencies needed to run kconfig, when previously kconfig had
.shipped versions of those files so as NOT to require that.
I just bisected the v5.14 regression where building x86-64 breaks trying to
#include "gelf.h" (from Jim Henson's Dark Crystal package), which I already
personally fought off in 2018 for my own builds:
https://twitter.com/landley/status/1064994639487426560
And the commit I just bisected it to
(http://lkml.iu.edu/hypermail/linux/kernel/2110.3/00009.html) EXPLICITLY broke
x86-64 (and only x86-64) to have a unique build-time dependency. In a patch that
did NOTHING ELSE. Because why not?
> although there is the occasional
> patch to address a micro-symptom of the problem. But no one
> is riding herd over the entire kernel to make sure that it doesn't
> get too big, or boot too slow (or use too much power).
Because the lkml clique is circling the wagons tighter and tighter until they
achieve a black hole via proctology? There doesn't seem to be any actual malice,
just a whole lot of territoriality and disdain for outsiders.
It's not a thing that somebody's gonna do for fun, a topic you and I emailed
about earlier this year if I recall.
> This entry, and the linux-embedded mailing list itself, have not
> functioned as originally intended in years, and I doubt anyone
> uses this information. The tools don't use it
> (e.g. get_maintainers.pl is never going to use this entry to
> recommend someone be CC'ed on an "embedded" patch).
Because that perl script matches files and the maintainers entry has no files.
(Not that cc-ing random patches to lists strikes me as particularly useful. It
usually just drives down the signal to noise ratio of the list in my experience.
Patch 22/47 applies to arch/sh and thus the whole series is cc'd there...)
> So, I guess I'd vote to get rid of it as well.
>
> But, I'm a little sad to see it go... :-(
> I'll probably never see Linux on a cereal box.
Oh there's plenty of people doing good work.
I talk to Jeff Dionne daily, he's working on that sort of thing. I email Elliott
Hughes (basically the android maintainer) multiple times per week. I talk to
Rich Felker by voice every week (we're on the same wednesday call), and email or
irc more often. (I feel guilty about dragging Elliott and Rich into
https://www.mail-archive.com/austin-group-l@opengroup.org/msg08569.html because
I underestimated the amount of bikeshedding on a list that's primarily posts
from the bug tracker and meeting announcements/minutes.)
None of them particularly participate in linux-kernel (despite Rich being
arch/sh maintainer, and yes I poke him about that every wednesday) because that
community comes across to us outsiders as a toxic insular clique that does not
remotely understand any of our needs, and acts threatened if we try to explain
them. Not because we CAN'T, but because it DOESN'T HELP WHEN WE TRY.
I'm the one who's considered weird for still (occasionally) engaging. Mostly as
bug reports like the above, or patches I post so when somebody sues I can go
"here it is in the list archives, not my fault they didn't merge it", or
one-offs I expect to be ignored (ala
http://lkml.iu.edu/hypermail/linux/kernel/2110.1/03713.html) although sometimes
there's a discussion that peters out without resolution instead (ala
http://lkml.iu.edu/hypermail/linux/kernel/2110.1/09327.html).
*shrug* Just stubborn I guess.
> -- Tim
Rob
^ permalink raw reply
* RE: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Tim.Bird @ 2021-10-19 22:54 UTC (permalink / raw)
To: khilman, geert, laurent.pinchart
Cc: dwmw2, tbird20d, u.kleine-koenig, linux-kernel, paul.gortmaker,
linux-embedded, herbert, linux-crypto, kernel, mporter, tglx,
thomas.petazzoni
In-Reply-To: <7hlf2oejqv.fsf@baylibre.com>
> -----Original Message-----
> From: Kevin Hilman <khilman@baylibre.com>
>
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
> > On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> >> On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote:
> >> > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote:
> >> > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
> >> > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
> >> > > > is long-overdue.
> >> > > >
> >> > > > No offense to any of the 3 persons listed, but I think the kernel developer
> >> > > > community would be better served by a group of individuals with a more
> >> > > > current active role in embedded linux. I have a few names I'll
> >> > > > toss out for
> >> > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
> >> > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
> >> > > > myself).
> >> > > >
> >> > > > This entry in the MAINTAINERS file is somewhat special, in that it
> >> > > > covers a "field of endeavor" rather than a specific set of files or
> >> > > > directories.
> >> > > >
> >> > > > Thoughts?
> >> > >
> >> > > Thank you for volunteering me :-)
> >> > >
> >> > > I was indeed wondering about this particular MAINTAINERS entry. As it
> >> > > doesn't cover any particular set of files, directories, drivers,
> >> > > subsystems or architectures, what does being listed here endeavour ?
> >> >
> >> > Basically nothing; I was going to suggest removing it entirely. There's
> >> > certainly no point listing me there any more.
> >> >
> >> > Once upon a time it involved a certain amount of heckling about memory
> >> > usage and "your hash table doesn't need to be that large" but that ship
> >> > sailed a long time ago :)
> >>
> >> Heckling is still an option without a MAINTAINERS entry I suppose :-)
> >
> > Don't worry, I keep on sailing ;-)
> >
> >> I wouldn't object if we were to remove it.
> >
> > +1
> >
>
> Agreed. Let's just drop this entry.
Well... Let me give some history, and then pontificate a little on the entry.
Originally, this entry was created after Andrew Morton gave a talk at
an early Embedded Linux Conference, saying that there should be some
"ombudsman" for embedded issues in the kernel. This was in 2008.
The linux-embedded mailing list was created about the same time.
The thinking was that there are issues that transcend any particular
sub-system, directory, or file, such as boot time or system size or
real-time. Changes to keep these system-wide metrics in check might
need the assistance of a respected upstream maintainer, who could
guide developers working in these areas, or who could help keep
other kernel maintainers apprised of requirements in these areas
for embedded products.
I would say that realtime has been shepherded pretty well by Thomas
Gleixner (and it's almost all upstream!), independent of this entry.
The other system-wide issues (boot time and system size), people
have pretty much given up on, although there is the occasional
patch to address a micro-symptom of the problem. But no one
is riding herd over the entire kernel to make sure that it doesn't
get too big, or boot too slow (or use too much power).
This entry, and the linux-embedded mailing list itself, have not
functioned as originally intended in years, and I doubt anyone
uses this information. The tools don't use it
(e.g. get_maintainers.pl is never going to use this entry to
recommend someone be CC'ed on an "embedded" patch).
So, I guess I'd vote to get rid of it as well.
But, I'm a little sad to see it go... :-(
I'll probably never see Linux on a cereal box.
-- Tim
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Kevin Hilman @ 2021-10-19 22:24 UTC (permalink / raw)
To: Geert Uytterhoeven, Laurent Pinchart
Cc: David Woodhouse, Tim Bird, Uwe Kleine-König,
Linux Kernel Mailing List, Paul Gortmaker, Linux Embedded,
Herbert Xu, Linux Crypto Mailing List, Sascha Hauer, Matt Porter,
Thomas Gleixner, Thomas Petazzoni, Tim Bird
In-Reply-To: <CAMuHMdVCrC5_AjNDJN+nwrnn=EVTfD-8ddG=FaFBBh_0UY5acQ@mail.gmail.com>
Geert Uytterhoeven <geert@linux-m68k.org> writes:
> On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote:
>> > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote:
>> > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
>> > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
>> > > > is long-overdue.
>> > > >
>> > > > No offense to any of the 3 persons listed, but I think the kernel developer
>> > > > community would be better served by a group of individuals with a more
>> > > > current active role in embedded linux. I have a few names I'll
>> > > > toss out for
>> > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
>> > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
>> > > > myself).
>> > > >
>> > > > This entry in the MAINTAINERS file is somewhat special, in that it
>> > > > covers a "field of endeavor" rather than a specific set of files or
>> > > > directories.
>> > > >
>> > > > Thoughts?
>> > >
>> > > Thank you for volunteering me :-)
>> > >
>> > > I was indeed wondering about this particular MAINTAINERS entry. As it
>> > > doesn't cover any particular set of files, directories, drivers,
>> > > subsystems or architectures, what does being listed here endeavour ?
>> >
>> > Basically nothing; I was going to suggest removing it entirely. There's
>> > certainly no point listing me there any more.
>> >
>> > Once upon a time it involved a certain amount of heckling about memory
>> > usage and "your hash table doesn't need to be that large" but that ship
>> > sailed a long time ago :)
>>
>> Heckling is still an option without a MAINTAINERS entry I suppose :-)
>
> Don't worry, I keep on sailing ;-)
>
>> I wouldn't object if we were to remove it.
>
> +1
>
Agreed. Let's just drop this entry.
Kevin
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Geert Uytterhoeven @ 2021-10-19 9:56 UTC (permalink / raw)
To: Laurent Pinchart
Cc: David Woodhouse, Tim Bird, Uwe Kleine-König,
Linux Kernel Mailing List, Paul Gortmaker, Linux Embedded,
Herbert Xu, Linux Crypto Mailing List, Sascha Hauer, Matt Porter,
Kevin Hilman, Thomas Gleixner, Thomas Petazzoni, Tim Bird
In-Reply-To: <YW6UGP10hfGJ2kYy@pendragon.ideasonboard.com>
On Tue, Oct 19, 2021 at 11:48 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote:
> > On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote:
> > > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
> > > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
> > > > is long-overdue.
> > > >
> > > > No offense to any of the 3 persons listed, but I think the kernel developer
> > > > community would be better served by a group of individuals with a more
> > > > current active role in embedded linux. I have a few names I'll
> > > > toss out for
> > > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
> > > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
> > > > myself).
> > > >
> > > > This entry in the MAINTAINERS file is somewhat special, in that it
> > > > covers a "field of endeavor" rather than a specific set of files or
> > > > directories.
> > > >
> > > > Thoughts?
> > >
> > > Thank you for volunteering me :-)
> > >
> > > I was indeed wondering about this particular MAINTAINERS entry. As it
> > > doesn't cover any particular set of files, directories, drivers,
> > > subsystems or architectures, what does being listed here endeavour ?
> >
> > Basically nothing; I was going to suggest removing it entirely. There's
> > certainly no point listing me there any more.
> >
> > Once upon a time it involved a certain amount of heckling about memory
> > usage and "your hash table doesn't need to be that large" but that ship
> > sailed a long time ago :)
>
> Heckling is still an option without a MAINTAINERS entry I suppose :-)
Don't worry, I keep on sailing ;-)
> I wouldn't object if we were to remove it.
+1
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Laurent Pinchart @ 2021-10-19 9:47 UTC (permalink / raw)
To: David Woodhouse
Cc: Tim Bird, Uwe Kleine-König, Linux Kernel Mailing List,
Paul Gortmaker, linux-embedded, Herbert Xu, linux-crypto, kernel,
Matt Porter, Kevin Hilman, Thomas Gleixner, thomas.petazzoni,
Tim Bird
In-Reply-To: <57122a67509bebdf0d1b9f5bc15db116e0124e5d.camel@infradead.org>
On Tue, Oct 19, 2021 at 10:33:10AM +0100, David Woodhouse wrote:
> On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote:
> > Hi Tim,
> >
> > On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
> > > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
> > > is long-overdue.
> > >
> > > No offense to any of the 3 persons listed, but I think the kernel developer
> > > community would be better served by a group of individuals with a more
> > > current active role in embedded linux. I have a few names I'll
> > > toss out for
> > > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
> > > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
> > > myself).
> > >
> > > This entry in the MAINTAINERS file is somewhat special, in that it
> > > covers a "field of endeavor" rather than a specific set of files or
> > > directories.
> > >
> > > Thoughts?
> >
> > Thank you for volunteering me :-)
> >
> > I was indeed wondering about this particular MAINTAINERS entry. As it
> > doesn't cover any particular set of files, directories, drivers,
> > subsystems or architectures, what does being listed here endeavour ?
>
> Basically nothing; I was going to suggest removing it entirely. There's
> certainly no point listing me there any more.
>
> Once upon a time it involved a certain amount of heckling about memory
> usage and "your hash table doesn't need to be that large" but that ship
> sailed a long time ago :)
Heckling is still an option without a MAINTAINERS entry I suppose :-)
I wouldn't object if we were to remove it.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: David Woodhouse @ 2021-10-19 9:33 UTC (permalink / raw)
To: Laurent Pinchart, Tim Bird
Cc: Uwe Kleine-König, Linux Kernel Mailing List, Paul Gortmaker,
linux-embedded, Herbert Xu, linux-crypto, kernel, Matt Porter,
Kevin Hilman, Thomas Gleixner, thomas.petazzoni, Tim Bird
In-Reply-To: <YW5r61ZQx+E9xfuH@pendragon.ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]
On Tue, 2021-10-19 at 09:55 +0300, Laurent Pinchart wrote:
> Hi Tim,
>
> On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
> > I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
> > is long-overdue.
> >
> > No offense to any of the 3 persons listed, but I think the kernel developer
> > community would be better served by a group of individuals with a more
> > current active role in embedded linux. I have a few names I'll
> > toss out for
> > candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
> > Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
> > myself).
> >
> > This entry in the MAINTAINERS file is somewhat special, in that it
> > covers a "field of endeavor" rather than a specific set of files or
> > directories.
> >
> > Thoughts?
>
> Thank you for volunteering me :-)
>
> I was indeed wondering about this particular MAINTAINERS entry. As it
> doesn't cover any particular set of files, directories, drivers,
> subsystems or architectures, what does being listed here endeavour ?
Basically nothing; I was going to suggest removing it entirely. There's
certainly no point listing me there any more.
Once upon a time it involved a certain amount of heckling about memory
usage and "your hash table doesn't need to be that large" but that ship
sailed a long time ago :)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Laurent Pinchart @ 2021-10-19 6:55 UTC (permalink / raw)
To: Tim Bird
Cc: Uwe Kleine-König, Linux Kernel Mailing List, Paul Gortmaker,
David Woodhouse, linux-embedded, Herbert Xu, linux-crypto, kernel,
Matt Porter, Kevin Hilman, Thomas Gleixner, thomas.petazzoni,
Tim Bird
In-Reply-To: <CA+bK7J741D=DgZMNeEC5xg9kDDSaJu19QsRunVvXkBGx1mKGnQ@mail.gmail.com>
Hi Tim,
On Mon, Oct 18, 2021 at 03:17:22PM -0600, Tim Bird wrote:
> On Mon, Sep 20, 2021 at 3:52 AM Uwe Kleine-König wrote:
> >
> > The mails I sent to Matt on September 14 and 20 both were refused by the
> > MTA responsible for selenic.com (i.e. waste.org) with:
> >
> > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete
> >
> > Also the most recent commit that involved him (ignoring "Cc: Matt
> > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS:
> > Theodore Ts'o is taking over the random driver) where he was removed
> > from the entry for random number drivers in 2012.
> >
> > So drop him completely from the list of maintainers.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > MAINTAINERS | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d7b4f32875a9..805630c67a1f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/
> >
> > EMBEDDED LINUX
> > M: Paul Gortmaker <paul.gortmaker@windriver.com>
> > -M: Matt Mackall <mpm@selenic.com>
> > M: David Woodhouse <dwmw2@infradead.org>
> > L: linux-embedded@vger.kernel.org
> > S: Maintained
> > @@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h
> > K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info)
>
>
> I think an overhaul of the "EMBEDDED LINUX" MAINTAINERS entry
> is long-overdue.
>
> No offense to any of the 3 persons listed, but I think the kernel developer
> community would be better served by a group of individuals with a more
> current active role in embedded linux. I have a few names I'll toss out for
> candidates: Matt Porter, Kevin Hilman, Thomas Gleixner, Thomas
> Petazonni, Laurent Pinchart, and Uwe Kleine-König (and maybe even
> myself).
>
> This entry in the MAINTAINERS file is somewhat special, in that it
> covers a "field of endeavor" rather than a specific set of files or
> directories.
>
> Thoughts?
Thank you for volunteering me :-)
I was indeed wondering about this particular MAINTAINERS entry. As it
doesn't cover any particular set of files, directories, drivers,
subsystems or architectures, what does being listed here endeavour ?
> ... Volunteers?
>
> > HARDWARE RANDOM NUMBER GENERATOR CORE
> > -M: Matt Mackall <mpm@selenic.com>
> > M: Herbert Xu <herbert@gondor.apana.org.au>
> > L: linux-crypto@vger.kernel.org
> > S: Odd fixes
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Uwe Kleine-König @ 2021-09-23 18:51 UTC (permalink / raw)
To: Olivia Mackall, Geert Uytterhoeven
Cc: Herbert Xu, Linux Embedded, Linux Kernel Mailing List,
Paul Gortmaker, Linux Crypto Mailing List, Sascha Hauer,
David Woodhouse
In-Reply-To: <CAMuHMdVAjtF2GKXgHgbmjUnMdWxqSpusKV_EieF2wEWezdqrPQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
Hello,
On Mon, Sep 20, 2021 at 03:01:25PM +0200, Geert Uytterhoeven wrote:
> On Mon, Sep 20, 2021 at 11:52 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > The mails I sent to Matt on September 14 and 20 both were refused by the
> > MTA responsible for selenic.com (i.e. waste.org) with:
> >
> > 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete
> >
> > Also the most recent commit that involved him (ignoring "Cc: Matt
> > Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS:
> > Theodore Ts'o is taking over the random driver) where he was removed
> > from the entry for random number drivers in 2012.
> >
> > So drop him completely from the list of maintainers.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > MAINTAINERS | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d7b4f32875a9..805630c67a1f 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/
> >
> > EMBEDDED LINUX
> > M: Paul Gortmaker <paul.gortmaker@windriver.com>
> > -M: Matt Mackall <mpm@selenic.com>
>
> Perhaps this should be replaced by
> "Olivia Mackall <olivia@selenic.com>" instead?
I think we need some feedback from Olivia here? At least I don't know
more than I wrote in the commit log and so I'm not in a position to
decide anything here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Geert Uytterhoeven @ 2021-09-20 13:01 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Linux Kernel Mailing List, Paul Gortmaker, David Woodhouse,
Linux Embedded, Herbert Xu, Linux Crypto Mailing List,
Sascha Hauer, Olivia Mackall
In-Reply-To: <20210920080635.253826-1-u.kleine-koenig@pengutronix.de>
Hi Uwe,
On Mon, Sep 20, 2021 at 11:52 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> The mails I sent to Matt on September 14 and 20 both were refused by the
> MTA responsible for selenic.com (i.e. waste.org) with:
>
> 554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete
>
> Also the most recent commit that involved him (ignoring "Cc: Matt
> Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS:
> Theodore Ts'o is taking over the random driver) where he was removed
> from the entry for random number drivers in 2012.
>
> So drop him completely from the list of maintainers.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> MAINTAINERS | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d7b4f32875a9..805630c67a1f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/
>
> EMBEDDED LINUX
> M: Paul Gortmaker <paul.gortmaker@windriver.com>
> -M: Matt Mackall <mpm@selenic.com>
Perhaps this should be replaced by
"Olivia Mackall <olivia@selenic.com>" instead?
> M: David Woodhouse <dwmw2@infradead.org>
> L: linux-embedded@vger.kernel.org
> S: Maintained
> @@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h
> K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info)
>
> HARDWARE RANDOM NUMBER GENERATOR CORE
> -M: Matt Mackall <mpm@selenic.com>
> M: Herbert Xu <herbert@gondor.apana.org.au>
> L: linux-crypto@vger.kernel.org
> S: Odd fixes
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
From: Uwe Kleine-König @ 2021-09-20 8:06 UTC (permalink / raw)
To: linux-kernel, Paul Gortmaker, David Woodhouse, linux-embedded,
Herbert Xu, linux-crypto
Cc: kernel
The mails I sent to Matt on September 14 and 20 both were refused by the
MTA responsible for selenic.com (i.e. waste.org) with:
554 5.7.1 <mpm@selenic.com>: Recipient address rejected: This identity is obsolete
Also the most recent commit that involved him (ignoring "Cc: Matt
Mackall <mpm@selenic.com>" footers) is commit 330e0a01d54c (MAINTAINERS:
Theodore Ts'o is taking over the random driver) where he was removed
from the entry for random number drivers in 2012.
So drop him completely from the list of maintainers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
MAINTAINERS | 2 --
1 file changed, 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d7b4f32875a9..805630c67a1f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6812,7 +6812,6 @@ F: drivers/media/usb/em28xx/
EMBEDDED LINUX
M: Paul Gortmaker <paul.gortmaker@windriver.com>
-M: Matt Mackall <mpm@selenic.com>
M: David Woodhouse <dwmw2@infradead.org>
L: linux-embedded@vger.kernel.org
S: Maintained
@@ -8157,7 +8156,6 @@ F: include/trace/events/hwmon*.h
K: (devm_)?hwmon_device_(un)?register(|_with_groups|_with_info)
HARDWARE RANDOM NUMBER GENERATOR CORE
-M: Matt Mackall <mpm@selenic.com>
M: Herbert Xu <herbert@gondor.apana.org.au>
L: linux-crypto@vger.kernel.org
S: Odd fixes
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
From: Petr Mladek via iommu @ 2021-05-20 12:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Marco Elver, Linux Embedded, John Ogness, Linus Torvalds,
Randy Dunlap, Rasmus Villemoes, Linux Kernel Mailing List,
Steven Rostedt, Sergey Senozhatsky, Linux IOMMU, Ingo Molnar,
Geert Uytterhoeven, Andrew Morton, Andy Shevchenko, Will Deacon,
Vlastimil Babka
In-Reply-To: <CAMuHMdXQArCn9BS_8p0iUAgomfEHWe8ypg=B_SGfvJu8c_L5vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon 2021-05-17 08:21:12, Geert Uytterhoeven wrote:
> On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven
> <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> > While long fancy messages have a higher probability of being seen than
> > small messages, they may scroll of the screen fast, if visible at all,
> > and may still be missed. In addition, they increase boot time and
> > kernel size.
> >
> > The correct mechanism to increase importance of a kernel message is not
> > to draw fancy boxes with more text, but to shout louder, i.e. increase
> > the message's reporting level. Making sure the administrator of the
> > system is aware of such a message is a system policy, and is the
> > responsability of a user-space log daemon.
> >
> > Fix this by increasing the reporting level from KERN_WARNING to
> > KERN_CRIT, and removing irrelevant text and graphics.
> >
> > This reduces kernel size by ca. 0.5 KiB.
> >
> > Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>
> No comments?
> Unlike the cases handled by the other two patches in this series,
> this one cannot be configured out.
IMHO, the best solution would be to create a generic API for
eye-catching messages.
I am sure that WARN() is misused on many locations all over the kernel
because people just wanted eye-catching message, for example, see
https://lore.kernel.org/r/2149df3f542d25ce15d049e81d6188bb7198478c.camel-RPVEmwYF7IOGWTQfUlqXWgC/G2K4zDHf@public.gmane.org
It might be a win-win solution.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
From: Geert Uytterhoeven @ 2021-05-17 6:21 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Steven Rostedt, Ingo Molnar,
Petr Mladek, Sergey Senozhatsky
Cc: Marco Elver, Linux Embedded, John Ogness, Randy Dunlap,
Rasmus Villemoes, Linux Kernel Mailing List, Linux IOMMU,
Geert Uytterhoeven, Andrew Morton, Andy Shevchenko,
Linus Torvalds, Vlastimil Babka
In-Reply-To: <20210331093104.383705-4-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven
<geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> While long fancy messages have a higher probability of being seen than
> small messages, they may scroll of the screen fast, if visible at all,
> and may still be missed. In addition, they increase boot time and
> kernel size.
>
> The correct mechanism to increase importance of a kernel message is not
> to draw fancy boxes with more text, but to shout louder, i.e. increase
> the message's reporting level. Making sure the administrator of the
> system is aware of such a message is a system policy, and is the
> responsability of a user-space log daemon.
>
> Fix this by increasing the reporting level from KERN_WARNING to
> KERN_CRIT, and removing irrelevant text and graphics.
>
> This reduces kernel size by ca. 0.5 KiB.
>
> Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed")
> Signed-off-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
No comments?
Unlike the cases handled by the other two patches in this series,
this one cannot be configured out.
Thanks!
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2193,20 +2193,9 @@ static int __init no_hash_pointers_enable(char *str)
>
> no_hash_pointers = true;
>
> - pr_warn("**********************************************************\n");
> - pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
> - pr_warn("** **\n");
> - pr_warn("** This system shows unhashed kernel memory addresses **\n");
> - pr_warn("** via the console, logs, and other interfaces. This **\n");
> - pr_warn("** might reduce the security of your system. **\n");
> - pr_warn("** **\n");
> - pr_warn("** If you see this message and you are not debugging **\n");
> - pr_warn("** the kernel, report this immediately to your system **\n");
> - pr_warn("** administrator! **\n");
> - pr_warn("** **\n");
> - pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
> - pr_warn("**********************************************************\n");
> -
> + pr_crit("This system shows unhashed kernel memory addresses\n");
> + pr_crit("via the console, logs, and other interfaces. This\n");
> + pr_crit("might reduce the security of your system.\n");
> return 0;
> }
> early_param("no_hash_pointers", no_hash_pointers_enable);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
From: Robin Murphy @ 2021-04-01 11:28 UTC (permalink / raw)
To: Geert Uytterhoeven, Steven Rostedt
Cc: Petr Mladek, Marco Elver, Linux Embedded, John Ogness,
Will Deacon, Randy Dunlap, Rasmus Villemoes,
Linux Kernel Mailing List, Sergey Senozhatsky, Linux IOMMU,
Ingo Molnar, Gary R Hook, Andrew Morton, Andy Shevchenko,
Linus Torvalds, Vlastimil Babka
In-Reply-To: <CAMuHMdUvgRiYfsVOJdocB3peLhnDWe=Kn1MLW64sh8zpd2XoLA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2021-04-01 10:39, Geert Uytterhoeven wrote:
> Hi Steven,
>
> On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
>> On Wed, 31 Mar 2021 11:31:03 +0200
>> Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>>
>>> This reduces kernel size by ca. 0.5 KiB.
>>
>> If you are worried about size, disable tracing and it will go away
>> entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
>> size overhead.
>
> Fair enough for this particular case, as tracing can be disabled.
I think the same argument can be applied to patch #1 - it's hard to
imaging anyone debugging an IOMMU driver on a system where a few hundred
bytes makes the slightest bit of difference, and for people not
debugging IOMMU drivers it should be moot (per the message itself).
Robin.
^ permalink raw reply
* Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
From: Geert Uytterhoeven @ 2021-04-01 9:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Marco Elver, Linux Embedded, John Ogness,
Linus Torvalds, Randy Dunlap, Rasmus Villemoes,
Linux Kernel Mailing List, Sergey Senozhatsky, Linux IOMMU,
Ingo Molnar, Vlastimil Babka, Andrew Morton, Andy Shevchenko,
Will Deacon, Gary R Hook
In-Reply-To: <20210331094007.77aa5194-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
Hi Steven,
On Wed, Mar 31, 2021 at 3:40 PM Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
> size overhead.
Fair enough for this particular case, as tracing can be disabled.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
From: Petr Mladek via iommu @ 2021-04-01 9:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: Marco Elver, linux-embedded-u79uwXL29TY76Z2rM5mHXA, John Ogness,
Geert Uytterhoeven, Linus Torvalds, Randy Dunlap,
Rasmus Villemoes, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Sergey Senozhatsky,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
Vlastimil Babka, Andrew Morton, Andy Shevchenko, Will Deacon,
Gary R Hook
In-Reply-To: <20210331094007.77aa5194-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
On Wed 2021-03-31 09:40:07, Steven Rostedt wrote:
> On Wed, 31 Mar 2021 11:31:03 +0200
> Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
>
> > This reduces kernel size by ca. 0.5 KiB.
>
> If you are worried about size, disable tracing and it will go away
> entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
> size overhead.
>
> Sorry, but NAK.
>
> This has been very successful in stopping people from adding trace_printk()
> to the kernel, and I like to keep it that way.
I agree with Steven. I believe that the eye-catching form is
important.
Anyway, all three patches are replacing text that have
many common parts. It is:
pr_warn("\n");
pr_warn("**********************************************************\n");
pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
pr_warn("** **\n");
pr_warn("** <Something is enabled/used.> **\n");
pr_warn("** **\n");
pr_warn("** <Description of the effect and why it should not **\n");
pr_warn("** happen on production kernel> **\n");
pr_warn("** **\n");
pr_warn("** If you see this message and you are not debugging **\n");
pr_warn("** the kernel, report this immediately to your vendor! **\n");
pr_warn("** **\n");
pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
pr_warn("**********************************************************\n");
It might be useful to avoid cut&pasting this entire blob and unify the
common parts.
My only concern is how to define the caller-specific lines so that
they fit with the common ones. They should not be longer than the
header and footer. We need to find a good compromise between
usability and over-engineering.
Also we have to keep bikeshading under control ;-)
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
From: Steven Rostedt @ 2021-03-31 13:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Petr Mladek, Marco Elver, linux-embedded-u79uwXL29TY76Z2rM5mHXA,
John Ogness, Linus Torvalds, Randy Dunlap, Rasmus Villemoes,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sergey Senozhatsky,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Ingo Molnar,
Vlastimil Babka, Andrew Morton, Andy Shevchenko, Will Deacon,
Gary R Hook
In-Reply-To: <20210331093104.383705-3-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Wed, 31 Mar 2021 11:31:03 +0200
Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org> wrote:
> This reduces kernel size by ca. 0.5 KiB.
If you are worried about size, disable tracing and it will go away
entirely. 0.5KiB is a drop in the bucket compared to what tracing adds in
size overhead.
Sorry, but NAK.
This has been very successful in stopping people from adding trace_printk()
to the kernel, and I like to keep it that way.
-- Steve
^ permalink raw reply
* [PATCH] clk: Align provider-specific CLK_* bit definitions
From: Geert Uytterhoeven @ 2021-03-31 9:59 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Steven Rostedt, Ingo Molnar,
Petr Mladek, Sergey Senozhatsky
Cc: Linus Torvalds, Andrew Morton, Andy Shevchenko, Rasmus Villemoes,
John Ogness, Gary R Hook, Marco Elver, Randy Dunlap,
Vlastimil Babka, iommu, linux-kernel, linux-embedded,
Geert Uytterhoeven
The definition of CLK_MULTIPLIER_ROUND_CLOSEST is not aligned to the two
bit definitions next to it. A deeper inspection reveals that the
alignment of CLK_MULTIPLIER_ROUND_CLOSEST does match the most common
alignment.
Align the bit definitions for the various provider types throughout the
file at 40 columns, to increase uniformity.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
include/linux/clk-provider.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 58f6fe866ae9b797..8f37829565f9640e 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -342,7 +342,7 @@ struct clk_fixed_rate {
unsigned long flags;
};
-#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
+#define CLK_FIXED_RATE_PARENT_ACCURACY BIT(0)
extern const struct clk_ops clk_fixed_rate_ops;
struct clk_hw *__clk_hw_register_fixed_rate(struct device *dev,
@@ -984,8 +984,8 @@ struct clk_fractional_divider {
#define to_clk_fd(_hw) container_of(_hw, struct clk_fractional_divider, hw)
-#define CLK_FRAC_DIVIDER_ZERO_BASED BIT(0)
-#define CLK_FRAC_DIVIDER_BIG_ENDIAN BIT(1)
+#define CLK_FRAC_DIVIDER_ZERO_BASED BIT(0)
+#define CLK_FRAC_DIVIDER_BIG_ENDIAN BIT(1)
extern const struct clk_ops clk_fractional_divider_ops;
struct clk *clk_register_fractional_divider(struct device *dev,
@@ -1033,9 +1033,9 @@ struct clk_multiplier {
#define to_clk_multiplier(_hw) container_of(_hw, struct clk_multiplier, hw)
-#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
+#define CLK_MULTIPLIER_ZERO_BYPASS BIT(0)
#define CLK_MULTIPLIER_ROUND_CLOSEST BIT(1)
-#define CLK_MULTIPLIER_BIG_ENDIAN BIT(2)
+#define CLK_MULTIPLIER_BIG_ENDIAN BIT(2)
extern const struct clk_ops clk_multiplier_ops;
--
2.25.1
^ permalink raw reply related
* [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
From: Geert Uytterhoeven @ 2021-03-31 9:31 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Steven Rostedt, Ingo Molnar,
Petr Mladek, Sergey Senozhatsky
Cc: Linus Torvalds, Andrew Morton, Andy Shevchenko, Rasmus Villemoes,
John Ogness, Gary R Hook, Marco Elver, Randy Dunlap,
Vlastimil Babka, iommu, linux-kernel, linux-embedded,
Geert Uytterhoeven
In-Reply-To: <20210331093104.383705-1-geert+renesas@glider.be>
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed. In addition, they increase boot time and
kernel size.
The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level. Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.
Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.
This reduces kernel size by ca. 0.5 KiB.
Fixes: 5ead723a20e0447b ("lib/vsprintf: no_hash_pointers prints all addresses as unhashed")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
lib/vsprintf.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 9b423359bb6433d3..0293f1b89064b287 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2193,20 +2193,9 @@ static int __init no_hash_pointers_enable(char *str)
no_hash_pointers = true;
- pr_warn("**********************************************************\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("** **\n");
- pr_warn("** This system shows unhashed kernel memory addresses **\n");
- pr_warn("** via the console, logs, and other interfaces. This **\n");
- pr_warn("** might reduce the security of your system. **\n");
- pr_warn("** **\n");
- pr_warn("** If you see this message and you are not debugging **\n");
- pr_warn("** the kernel, report this immediately to your system **\n");
- pr_warn("** administrator! **\n");
- pr_warn("** **\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("**********************************************************\n");
-
+ pr_crit("This system shows unhashed kernel memory addresses\n");
+ pr_crit("via the console, logs, and other interfaces. This\n");
+ pr_crit("might reduce the security of your system.\n");
return 0;
}
early_param("no_hash_pointers", no_hash_pointers_enable);
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
From: Geert Uytterhoeven @ 2021-03-31 9:31 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Steven Rostedt, Ingo Molnar,
Petr Mladek, Sergey Senozhatsky
Cc: Linus Torvalds, Andrew Morton, Andy Shevchenko, Rasmus Villemoes,
John Ogness, Gary R Hook, Marco Elver, Randy Dunlap,
Vlastimil Babka, iommu, linux-kernel, linux-embedded,
Geert Uytterhoeven
In-Reply-To: <20210331093104.383705-1-geert+renesas@glider.be>
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed. In addition, they increase boot time and
kernel size.
The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level. Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.
Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.
This reduces kernel size by ca. 0.5 KiB.
Fixes: 2184db46e425c2b8 ("tracing: Print nasty banner when trace_printk() is in use")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
kernel/trace/trace.c | 17 +++--------------
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index eccb4e1187cc788e..b3a93aff01045923 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3175,20 +3175,9 @@ void trace_printk_init_buffers(void)
/* trace_printk() is for debug use only. Don't use it in production. */
- pr_warn("\n");
- pr_warn("**********************************************************\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("** **\n");
- pr_warn("** trace_printk() being used. Allocating extra memory. **\n");
- pr_warn("** **\n");
- pr_warn("** This means that this is a DEBUG kernel and it is **\n");
- pr_warn("** unsafe for production use. **\n");
- pr_warn("** **\n");
- pr_warn("** If you see this message and you are not debugging **\n");
- pr_warn("** the kernel, report this immediately to your vendor! **\n");
- pr_warn("** **\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("**********************************************************\n");
+ pr_crit("trace_printk() being used. Allocating extra memory.\n");
+ pr_crit("This means that this is a DEBUG kernel and it is\n");
+ pr_crit("unsafe for production use.\n");
/* Expand the buffers to set size */
tracing_update_buffers();
--
2.25.1
^ permalink raw reply related
* [PATCH 1/3] iommu: Use pr_crit() instead of long fancy messages
From: Geert Uytterhoeven @ 2021-03-31 9:31 UTC (permalink / raw)
To: Joerg Roedel, Will Deacon, Steven Rostedt, Ingo Molnar,
Petr Mladek, Sergey Senozhatsky
Cc: Linus Torvalds, Andrew Morton, Andy Shevchenko, Rasmus Villemoes,
John Ogness, Gary R Hook, Marco Elver, Randy Dunlap,
Vlastimil Babka, iommu, linux-kernel, linux-embedded,
Geert Uytterhoeven
In-Reply-To: <20210331093104.383705-1-geert+renesas@glider.be>
While long fancy messages have a higher probability of being seen than
small messages, they may scroll of the screen fast, if visible at all,
and may still be missed. In addition, they increase boot time and
kernel size.
The correct mechanism to increase importance of a kernel message is not
to draw fancy boxes with more text, but to shout louder, i.e. increase
the message's reporting level. Making sure the administrator of the
system is aware of such a message is a system policy, and is the
responsability of a user-space log daemon.
Fix this by increasing the reporting level from KERN_WARNING to
KERN_CRIT, and removing irrelevant text and graphics.
This reduces kernel size by ca. 0.5 KiB.
Fixes: bad614b24293ae46 ("iommu: Enable debugfs exposure of IOMMU driver internals")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/iommu/iommu-debugfs.c | 19 ++++---------------
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/iommu-debugfs.c b/drivers/iommu/iommu-debugfs.c
index f0354894209648fd..c3306998de0687bd 100644
--- a/drivers/iommu/iommu-debugfs.c
+++ b/drivers/iommu/iommu-debugfs.c
@@ -32,20 +32,9 @@ void iommu_debugfs_setup(void)
{
if (!iommu_debugfs_dir) {
iommu_debugfs_dir = debugfs_create_dir("iommu", NULL);
- pr_warn("\n");
- pr_warn("*************************************************************\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("** **\n");
- pr_warn("** IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS KERNEL **\n");
- pr_warn("** **\n");
- pr_warn("** This means that this kernel is built to expose internal **\n");
- pr_warn("** IOMMU data structures, which may compromise security on **\n");
- pr_warn("** your system. **\n");
- pr_warn("** **\n");
- pr_warn("** If you see this message and you are not debugging the **\n");
- pr_warn("** kernel, report this immediately to your vendor! **\n");
- pr_warn("** **\n");
- pr_warn("** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **\n");
- pr_warn("*************************************************************\n");
+ pr_crit("IOMMU DebugFS SUPPORT HAS BEEN ENABLED IN THIS KERNEL\n");
+ pr_crit("This means that this kernel is built to expose internal\n");
+ pr_crit("IOMMU data structures, which may compromise security on\n");
+ pr_crit("your system.\n");
}
}
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox