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: <c28680b5-d262-97ae-5bdc-5cce9169e2da@roeck-us.net>
Date:   Mon, 29 Jul 2019 18:30:48 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Mark Balantzyan <mbalant3@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org,
        wim@...ux-watchdog.org
Subject: Re: [PATCH] watchdog device drivers:pc87413_wdt: Rewriting of
 pc87413_wdt driver to utilize common watchdog interface (fwd)

Mark,

On 7/29/19 5:44 PM, Mark Balantzyan wrote:
> Hello all, Guenter,
> 
> I am being evaluated as a student by my organization. I appreciate your patience with my emails and patches.
> 
> I would like to please propose that we divide and conquer: I write the code for converting the driver to common watchdog interface (and I thank you for your guidance on it in previous email) and you test the code on the actual hardware you may happen to have, as I do not have it. I accept the fact that it is indeed risky without the hardware to ensure the driver works correctly, but that will be where we work in tandem, software to hardware, yes, if that's alright?
> 

If I had the hardware, I would say so. Then we would have no problem,
I would thank you for your work, and I would be more than happy to test
your patch on that hardware.

Unfortunately, I don't have the hardware, and I don't know anyone who (still)
has. The most recent functional change to this driver was made back in 2011.

If the task is to convert a watchdog driver, does it have to be _this_ driver ?
One that comes into mind instead would be ib700, which looks to be quite similar
and which _is_ supported by qemu. I have not tried if its qemu emulation
actually works, but it would be worth a try.

The only alternative I can see, if it has to be _this_ driver for some reason,
is for us to go through with it and then let the patch hang around until we
find someone to test it (which may be never). I am not really sure if that
would be worth our time.

> I think it's better if I use git send-email for the corresponding patch with the improvements you forecasted since it may format things better and may result in a non-corrupted patching.
> 
Most definitely, yes.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ