[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b7b0b881-08b8-2b7d-fc09-3d9d79b90cea@huawei.com>
Date: Tue, 19 May 2020 22:11:11 +0800
From: "liwei (GF)" <liwei391@...wei.com>
To: Daniel Thompson <daniel.thompson@...aro.org>
CC: Doug Anderson <dianders@...omium.org>,
Jason Wessel <jason.wessel@...driver.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
<kgdb-bugreport@...ts.sourceforge.net>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] kdb: Make the internal env 'KDBFLAGS' undefinable
Hi Daniel,
On 2020/5/19 19:40, Daniel Thompson wrote:
> On Sat, May 16, 2020 at 05:26:06PM +0800, Wei Li wrote:
>> 'KDBFLAGS' is an internal variable of kdb, it is combined by 'KDBDEBUG'
>> and state flags. But the user can define an environment variable named
>> 'KDBFLAGS' too, so let's make it undefinable to avoid confusion.
>>
>> Signed-off-by: Wei Li <liwei391@...wei.com>
>> Reviewed-by: Douglas Anderson <dianders@...omium.org>
>
> I took a quick look at this and find myself thinking of KDBFLAGS as
> something of a misfeature.
>
> I think I'd rather get kdb_env to show the value we wrote into
> KDBDEBUG.
>
> Sure this means we cannot use KDBDEBUG to look at the least significant
> 16-bits but I think anyone who is debugging kdb itself should know
> enough to use `md4c1 kdb_flags` to read those anyway.
>
>
Agree. That will be more clear with no confusion. Currently,
KDBFLAGS will be shown only when KDBDEBUG is set, that is weird too.
So, let's just make it simple.
I can fix it as you suggested in the next post.
Thanks,
Wei
Powered by blists - more mailing lists