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!
next prev parent 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®