All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: linux-watchdog@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org,
	Guenter Roeck <linux@roeck-us.net>,
	Robin Gong <b38343@freescale.com>
Subject: Re: [PATCH 1/7] watchdog: add watchdog pretimeout framework
Date: Thu, 26 May 2016 18:41:36 +0200	[thread overview]
Message-ID: <20160526164136.GB1631@katana> (raw)
In-Reply-To: <5747041B.2050707@mentor.com>

[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]

Hi Vladimir,

great to see you still have capacity for this series :)

> The thing is that I'm particularly interested in
> 
> 1) sleeping governors,
> 2) userspace notification of any appropriate kind, but preferably not by
>    adding a clumsy .poll callback, uevent is the best IMHO.

I am totally open that poll might not be a good idea, but why do you
think uevent is best? (Disclaimer: I don't do much userspace code)

> The userspace sleeping governor is the only one proposed for a mainline,
> however the whole idea of having a framework is to allow users to write
> their own private governors, and that's exactly what we need and use.

One reason I decided to drop 'can_sleep' is that I guessed 98% of users
will be happy with the panic, noop, and userspace governers. 2% might
need custom governors from which maybe not even all need to sleep.
Chances are high IMO that these govenors will be out-of-tree code, so
having all this additional complexity for some out-of-tree govenors was
questionable to me. I wondered if it would make sense to let those
govenors do the bottom half handling themselves.

There was also a technical reason: The dev pointer was first moved to
watchdog_device private data before it was ultimately removed. So, while
trying to fix this, the code got more and more complicated which led me
to the decision to go the other way around: make the code simpler so it
will be easier maintainable in the future.

> So the original complexity has its state-of-the-art grounds, and for
> sake of getting a solid picture for reviewers and users it is better to
> introduce sleeping functionality right from the beginning.

I still wonder if bottom half handling shouldn't be put to the governors
which need that.

> I know it is quite complex, probably it might be better to add it to
> the series as a separate patch?

That might help the initial review.

> Thanks for pushing it, but do you think that the authorship of the
> code can be preserved?

I changed the authorship because I did one fundamental change to your
original design. Not knowing if you'd approve of that, I didn't want to
put your sticker on something you might not even like.

> Feel free to ask me to rebase the change and so on, patch review procedure
> is well established and I'm pretty sure I can cope with it.

No doubt about that. I had some ideas and thought it is easier to talk
over code. If you want to rebase it, too, I'd be happy to check what you
came up with to solve the problems. I might still argue that I prefer
the less-code approach, but it will be Guenter's / Wim's decision, of
course.

And I apologize for not contacting you beforehand which would have been
friendly. I got a rush on hacking it and wanted to show what I came up
with. No offence, sorry!

Thanks,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-05-26 16:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 13:32 [PATCH 0/7] watchdog: add pretimeout support Wolfram Sang
2016-05-25 13:32 ` [PATCH 1/7] watchdog: add watchdog pretimeout framework Wolfram Sang
2016-05-26 14:11   ` Vladimir Zapolskiy
2016-05-26 16:41     ` Wolfram Sang [this message]
2016-05-26 22:37       ` Guenter Roeck
2016-06-05  9:48         ` Wolfram Sang
2016-06-05 20:25           ` Vladimir Zapolskiy
2016-05-25 13:32 ` [PATCH 2/7] watchdog: pretimeout: add panic pretimeout governor Wolfram Sang
2016-05-25 13:32 ` [PATCH 3/7] watchdog: pretimeout: add noop " Wolfram Sang
2016-05-25 13:32 ` [PATCH 4/7] watchdog: documentation: squash paragraphs about 'no set_timeout' Wolfram Sang
2016-05-25 13:32 ` [PATCH 5/7] watchdog: add pretimeout support to the core Wolfram Sang
2016-05-25 13:32 ` [PATCH 6/7] fs: compat_ioctl: add pretimeout functions for watchdogs Wolfram Sang
2016-05-25 13:32 ` [PATCH 7/7] watchdog: softdog: implement pretimeout support Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160526164136.GB1631@katana \
    --to=wsa@the-dreams.de \
    --cc=b38343@freescale.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=vladimir_zapolskiy@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.