public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Li Zefan <lizf@cn.fujitsu.com>
To: Paul Menage <menage@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Allow cpusets to be configured/built on non-SMP systems
Date: Tue, 03 Mar 2009 16:54:33 +0800	[thread overview]
Message-ID: <49ACF049.8060306@cn.fujitsu.com> (raw)
In-Reply-To: <49ACED6A.9060002@cn.fujitsu.com>

Li Zefan wrote:
> Paul Menage wrote:
>> On Mon, Mar 2, 2009 at 10:01 PM, Paul Menage <menage@google.com> wrote:
>>> On Mon, Mar 2, 2009 at 7:17 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>>>>> +static int generate_sched_domains(struct cpumask **domains,
>>>>> +                     struct sched_domain_attr **attributes)
>>>>> +{
>>>> Except here should "return 0;", otherwise emit a compile warining.
>>>>
>>> Good catch - the weird thing is that (in my UML build) it doesn't
>>> actually generate that warning. Mysterious.
>>>
>>> I'll resend with the extra return.
>> After looking at the sched domains code it's not clear to me that
>> returning 0 is necessarily the right thing to do -
>> partition_sched_domains() says that 0 is a special case used for
>> destroying existing domains? Would returning 1 and setting up a single
>> dummy domain be better?
>>
> 

partition_sched_domains() says (0, NULL, ...) is used for destroying existing
domains, (1, NULL, ...) will fallback to the single default domain.

But partition_sched_domains() is a stub if !CONFIG_SMP

> Yes, return 1 seems more reasonable. And if we do this, should we also set
> *domains to NULL like this?
> 
> static int generate_sched_domains(struct cpumask **domains,
>                      struct sched_domain_attr **attributes)
> {
> 	*domains = NULL;
> 	return 1;
> }
> 

  reply	other threads:[~2009-03-03  8:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-03  1:36 [PATCH] Allow cpusets to be configured/built on non-SMP systems Paul Menage
2009-03-03  2:01 ` Li Zefan
2009-03-03  3:17 ` Li Zefan
2009-03-03  6:01   ` Paul Menage
2009-03-03  6:41     ` Paul Menage
2009-03-03  8:26     ` Paul Menage
2009-03-03  8:42       ` Li Zefan
2009-03-03  8:54         ` Li Zefan [this message]
2009-03-03  8:07 ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-03-03 23:52 Paul Menage

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=49ACF049.8060306@cn.fujitsu.com \
    --to=lizf@cn.fujitsu.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    /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