From: Patrick Mochel <mochel@osdl.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: <torvalds@osdl.org>, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you?
Date: Fri, 22 Aug 2003 14:25:46 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.33.0308221411060.2310-100000@localhost.localdomain> (raw)
In-Reply-To: <20030822210800.GA4403@elf.ucw.cz>
> As far as I can see, I'm still maintainer of software suspend. That
> did not stop you from crying "split those patches" when I tried to
> submit changes to my code, and you were pretty pissed off when I tried
> to push trivial one liners without contacting maintainers.
Ok, I'm sorry. I should not have broken anything in your code, and
actually significantly improved it.
> And now you pushed ton of crap into Linus' tree, breaking userland
> interfaces in the stable series (/proc/acpi/sleep)
/proc/acpi/sleep is useless. For one, we want an interface that handles
quiescing the system that is not tied to a particular low-level details.
The ACPI bits are trivial. And, you really don't want an interface to
swsusp that depends on ACPI, do you?
On top of that, the way it was implemented was broken. You could not
actually enter a low-power state (S4) if you used swsusp. You had to
shutdown the system
> killing copyrights
> (Andy Grover has copyright on drivers/acpi/sleep/main.c)
Everything in that file, with the exception of one line fixes/checks, is
mine, from either 2 years ago or now.
> rewriting code without even sending diff to maintainer (no, I did not
> see a mail from you, and you modified swsusp heavily).
I removed code from swsusp and moved into a central, shared location. I
apoloigize for the hypocrasy on my part, but I contend that the result is
much prettier.
> Great. This way we are going to have stable PM code... in 2056.
Yes, but we should also have it a lot sooner than that.
Note that we have never had stable PM code; we've had crap. It is a lot
more stable now, based solely on the fact that someone has actually taken
the time to look at it, clean it up, and start fixing it.
What is your idea of stability? The point when all the people that report
bugs to you, and you reply 'Fix it yourself' actually buckle down and fix
all the problems? Or, when someone steps up and tries to make it work
reliably for a majority of users?
My intent is to do that, and to do it soon. And, with a minimal amount of
pain during the transitions.
> +
> +enum {
> + PM_SUSPEND_ON,
> + PM_SUSPEND_STANDBY,
> + PM_SUSPEND_MEM,
> + PM_SUSPEND_DISK,
> + PM_SUSPEND_MAX,
> +};
> +
> +extern int (*pm_power_down)(u32 state);
>
> If you defined enum, you should also use it.
As a typedef parameter to the function?
> static int __init resume_setup(char *str)
> {
> - strncpy( resume_file, str, 255 );
> + if (strlen(str))
> + strncpy(resume_file, str, 255);
> return 1;
> }
>
> Why are you obfuscating the code?
Eh? First, why would you want to copy a NULL string?
Secondly, you can actually remove the second command line parameter
("noresume") by simply specifying a NULL partition to this parameter. It
requires about a 5-line change, and makes things simpler.
> You changed return type of do_magic() to int, but did not bother to
> update assembly code, as far as I can see. Did you test those changes?
I noticed that, and it's already fixed.
> +Some devices are broken and will inevitably have problems powering
> +down or disabling themselves with interrupts enabled. For these
> +special cases, they may return -EAGAIN. This will put the device on a
> +list to be taken care of later. When interrupts are disabled, before
> +we enter the low-power state, their drivers are called again to put
> +their device to sleep.
>
> Returning EAGAIN to be called with interrupts disabled is extremely
> ugly hack. We were passing suspend level before. Why did you have to
> break it?
Because you can power down most devices with interrupts enabled, and you
really want to. Especially for devices that support runtime power
management, which by definition, requires interrupts to always be enabled.
-EAGAIN allows the drivers/devices that really need special care to
specify it. Otherwise, we'll end up calling ->suspend() twice for power
down for each device (those that can do w/ interrupts enabled and those
that need interrupts disabled), which also requires every single driver to
check whether or not interrupts are enabled, instead of just those that
need it.
Pat
next prev parent reply other threads:[~2003-08-22 21:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-22 21:08 [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you? Pavel Machek
2003-08-22 21:25 ` Patrick Mochel [this message]
2003-08-22 21:53 ` Pavel Machek
2003-08-22 22:05 ` Patrick Mochel
2003-08-23 1:03 ` Nigel Cunningham
2003-08-23 16:22 ` Benjamin Herrenschmidt
2003-08-25 19:05 ` [PM] powering down special devices Patrick Mochel
2003-08-25 19:53 ` Benjamin Herrenschmidt
2003-08-25 9:52 ` [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you? Pavel Machek
2003-08-22 22:10 ` Pavel Machek
2003-08-22 22:13 ` Patrick Mochel
2003-08-22 22:17 ` Patrick Mochel
2003-08-22 22:36 ` Pavel Machek
2003-08-23 10:47 ` Russell King
2003-08-24 11:54 ` Russell King
2003-08-26 15:39 ` [PM] Config Options Patrick Mochel
2003-08-24 12:08 ` [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you? Russell King
2003-08-25 15:47 ` Patrick Mochel
2003-08-25 16:27 ` Russell King
2003-08-25 16:57 ` Matt Porter
2003-08-25 17:14 ` Russell King
2003-08-25 17:34 ` Matt Porter
2003-08-28 15:38 ` Platform Devices Patrick Mochel
2003-09-01 12:02 ` [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you? Pavel Machek
2003-09-02 17:41 ` Jens Axboe
2003-09-09 20:19 ` Benjamin Herrenschmidt
2003-09-09 20:24 ` Jens Axboe
2003-09-09 21:43 ` Patrick Mochel
2003-09-09 22:54 ` Pavel Machek
2003-09-09 23:07 ` Patrick Mochel
2003-09-09 23:07 ` [PM] Passing suspend level down to drivers Pavel Machek
2003-09-09 23:23 ` Patrick Mochel
2003-09-10 0:06 ` Pavel Machek
2003-09-10 6:12 ` Stephen Rothwell
2003-09-10 11:48 ` Alan Cox
2003-09-09 23:15 ` [PM] Patrick: which part of "maintainer" and "peer review" needs explaining to you? Alan Cox
2003-09-09 22:56 ` Pavel Machek
2003-08-25 17:16 ` Russell King
2003-08-22 22:04 ` Timothy Miller
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=Pine.LNX.4.33.0308221411060.2310-100000@localhost.localdomain \
--to=mochel@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=torvalds@osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).