linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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).