mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	Swsusp mailing list <swsusp-devel@lists.sourceforge.net>
Subject: Re: SMP support for swsusp (this one actually works for me)
Date: Thu, 24 Jun 2004 23:38:58 +0200	[thread overview]
Message-ID: <20040624213858.GC20649@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0406241354340.32272-100000@monsoon.he.net>

Hi!

> > Here's SMP support for swsusp; this one actually works for me [with
> > keyboard hack], but I'd like more testers. If it looks okay, I'll
> > merge simple pieces with andrew.
> 
> This looks cool, but I have some aesthetic nits about it:

I'll kill #if 0s before attempting to merge.

> > +#ifdef CONFIG_SMP
> > +extern void smp_freeze(void);
> > +extern void smp_restart(void);
> > +#else
> > +static inline void smp_freeze(void) {}
> > +static inline void smp_restart(void) {}
> > +#endif
> 
> Could you name those something more explicit, like swsusp_smp_freeze(),
> etc, so you don't have potential namespace conflicts?

I guess that S3 sleep might find them usefull, too.

Perhaps calling them disable_nonboot_cpus() and enable_nonboot_cpus()
are better names?

> > -void save_processor_state(void)
> > +void __save_processor_state(struct saved_context *ctxt)
> 
> > +void save_processor_state(void)
> > +{
> > +	__save_processor_state(&saved_context);
> >  }
> 
> This also looks completely gratuitous and confusing - if you're not doing
> anything else but calling the __function, then why even create
> __function?

__save_processor_state() is needed from smp.c, save_processor_state()
is needed from swsusp.S. I did not want to break that for now.

> >  EXPORT_SYMBOL(save_processor_state);
> >  EXPORT_SYMBOL(restore_processor_state);
> 
> And, why are they exported in the first place?

Not sure... swsusp can't be modular so I should be able to just kill
this, right?

> > %diffstat
> >  Documentation/power/swsusp.txt   |    5 +
> >  Documentation/power/video.txt    |    4 +
...
> >  kernel/power/smp.c               |   85 ++++++++++++++++++++++++++++++
> >  kernel/power/swsusp.c            |   78 +++++++++++++++++++--------
> >  kernel/signal.c                  |    6 +-
> >  17 files changed, 293 insertions(+), 102 deletions(-)
> 
> Were there more files to the patch? Some of the ones listed here were not
> in the email?

I hand-edited the diff and forgot to kill this, sorry. Nothing should
be missing.

> BTW, nice work.

Thanks!
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

  reply	other threads:[~2004-06-24 21:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 12:17 Pavel Machek
2004-06-24 21:00 ` Patrick Mochel
2004-06-24 21:38   ` Pavel Machek [this message]
2004-06-25 15:27   ` Rik van Riel

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=20040624213858.GC20649@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@digitalimplant.org \
    --cc=swsusp-devel@lists.sourceforge.net \
    /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

all inboxes | Powered by JetHome®