[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <abd75184-1d33-4877-eef7-eeca436e5220@infradead.org>
Date: Thu, 20 Dec 2018 12:10:33 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Thorsten Leemhuis <linux@...mhuis.info>,
Jonathan Corbet <corbet@....net>
Cc: linux-doc@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/1] RFC: Revamp admin-guide/tainted-kernels.rst to make
it more comprehensible
On 12/20/18 10:21 AM, Thorsten Leemhuis wrote:
> Am 20.12.18 um 17:38 schrieb Randy Dunlap:
>> On 12/20/18 7:28 AM, Jonathan Corbet wrote:
>>> On Thu, 20 Dec 2018 16:23:38 +0100
>>> Thorsten Leemhuis <linux@...mhuis.info> wrote:
>>>
>>>> While at it: Jonathan, you mentioned putting the script in scripts/, but
>>>> according to the Makefile in that directory it is "for various helper
>>>> programs used throughout the kernel for the build process". That's one
>>>> reason why it feels wrong to put it there. Another one: that script
>>>> targets users and thus we should try to make sure they can access it
>>>> easily. That's why I'm currently inclined to put it in tools/ somewhere.
>>> Yeah, tools/ is a better place. Maybe a tools/debugging directory or some
>>> such?
>> chktaint
>
> BTW, I renamed it to kernel-taintstatus, sounded more appropriate to me.
> Does anyone mind?
Not terribly, although that seems too long to me. ;)
maybe 'taintstatus'?
>> is similar (IMO) to scripts/decodecode though.
>
> Hmmm. Maybe it would be better to move this to tools/? Will take a quick
> look, guess sooner or later by current endeavours will lead me to the
> documentation that refers to this script anyway.
>
>> @Thorsten:
>> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
>
> Thx. And thx for the feedback in the other reply.
>
> BTW, for those following this thread and my earlier quest for a simple
> cmd to decode /proc/sys/kernel/tainted: looks like @apexo on twitter
> (thx again!) found a trick to do what I want which should work on most
> systems out-of-the-box:
>
> $ for i in $(seq 18); do echo $i $(($(cat
> /proc/sys/kernel/tainted)>>($i-1)&1));done
I think Jon mentioned this: The output should begin with bit #0,
not bit #1, so it should show bits 0 - 17 (or whatever the max is),
not 1 - 18.
--
~Randy
Powered by blists - more mailing lists