linux-kernel - Re: [PATCH v5 2/3] watchdog: introduce watchdog.open

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <302570fe-6c4e-69fb-2e5a-7bad91edf45a@prevas.dk>
Date:   Tue, 30 May 2017 10:00:42 +0200
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Guenter Roeck <linux@...ck-us.net>,
        Wim Van Sebroeck <wim@...ana.be>,
        Jonathan Corbet <corbet@....net>
CC:     Sebastian Reichel <sebastian.reichel@...labora.co.uk>,
        <esben.haabendal@...il.com>, <linux-watchdog@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/3] watchdog: introduce watchdog.open_timeout
 commandline parameter

On 2017-05-25 02:56, Guenter Roeck wrote:
> On 05/22/2017 07:06 AM, Rasmus Villemoes wrote:
>> diff --git a/Documentation/watchdog/watchdog-parameters.txt
>> b/Documentation/watchdog/watchdog-parameters.txt
>> index 914518a..4801ec6 100644
>> --- a/Documentation/watchdog/watchdog-parameters.txt
>> +++ b/Documentation/watchdog/watchdog-parameters.txt
>> @@ -8,6 +8,15 @@ See Documentation/admin-guide/kernel-parameters.rst
>> for information on
>>   providing kernel parameters for builtin drivers versus loadable
>>   modules.
>>   +The watchdog core currently understands one parameter,
> 
> We have a second parameter queued, handle_boot_enabled. Please rephrase
> so we don't have to change the text with each new parameter.

I agree that it makes sense to rephrase to avoid having to edit when
other parameters are added, and I'll send v6 in a moment. But regarding
the handle_boot_enabled, I think my patch set implements a superset of
that functionality (just set watchdog.open_timeout to 1ms), which is why
I asked Sebastian specifically to look at the patches, and he said that
they'd work for his use case as well. So while I personally don't really
care if both go in, it does seem a little silly and somewhat confusing
to have two parameters to do more-or-less the same thing.

Btw, where can I find the watchdog-next tree (or whatever it's called)
to see what is queued up?

-- 
Rasmus Villemoes
Software Developer
Prevas A/S
Hedeager 1
DK-8200 Aarhus N
+45 51210274
rasmus.villemoes@...vas.dk
www.prevas.dk