All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Yanmin Zhang <ymzhang@unix-os.sc.intel.com>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org,
	linux-ia64@vger.kernel.org, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	"Shah, Rajesh" <rajesh.shah@intel.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	yanmin.zhang@intel.com
Subject: Re: [PATCH v2:3/3]Export cpu topology by sysfs
Date: Tue, 27 Dec 2005 05:36:10 +0000	[thread overview]
Message-ID: <20051227053610.GE25886@kroah.com> (raw)
In-Reply-To: <20051226002839.A24653@unix-os.sc.intel.com>

On Mon, Dec 26, 2005 at 12:28:39AM -0800, Yanmin Zhang wrote:
> On Mon, Dec 26, 2005 at 03:38:16PM +0800, Zhang, Yanmin wrote:
> > >>-----Original Message-----
> > >>From: Greg KH [mailto:greg@kroah.com]
> > >>Sent: 2005??12??24?? 3:16
> > >>To: Zhang, Yanmin
> > >>Cc: Yanmin Zhang; linux-kernel@vger.kernel.org; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah, Rajesh;
> > >>Pallipadi, Venkatesh
> > >>Subject: Re: [PATCH v2:3/3]Export cpu topology by sysfs
> > >>
> > >>On Fri, Dec 23, 2005 at 12:03:27PM +0800, Zhang, Yanmin wrote:
> > >>> >>Can't you just use an attribute group and attach it to the cpu kobject?
> > >>> >>That would save an array of kobjects I think.
> > >>> As you know, current i386/x86_64 arch also export cache info under
> > >>> /sys/device/system/cpu/cpuX/cache. Is it clearer to export topology
> > >>> under a new directory than under cpu directly?
> > >>
> > >>No, the place in the sysfs tree you are putting this is just fine.  I'm
> > >>just saying that you do not need to create a new kobject for these
> > >>attributes.  Just use an attribute group, and you will get the same
> > >>naming, without the need for an extra kobject (and the whole array of
> > >>kobjects) at all.
> > >>
> > >>Does that make more sense?
> > Yes, indeed. Now, I used your idea and the patch became simpler. Thanks.



> > 
> > 
> > >>
> > >>> >>> +static int __cpuinit topology_cpu_callback(struct notifier_block *nfb,
> > >>> >>> +		unsigned long action, void *hcpu)
> > >>> >>> +{
> > >>> >>> +	unsigned int cpu = (unsigned long)hcpu;
> > >>> >>> +	struct sys_device *sys_dev;
> > >>> >>> +
> > >>> >>> +	sys_dev = get_cpu_sysdev(cpu);
> > >>> >>> +	switch (action) {
> > >>> >>> +		case CPU_ONLINE:
> > >>> >>> +			topology_add_dev(sys_dev);
> > >>> >>> +			break;
> > >>> >>> +#ifdef	CONFIG_HOTPLUG_CPU
> > >>> >>> +		case CPU_DEAD:
> > >>> >>> +			topology_remove_dev(sys_dev);
> > >>> >>> +			break;
> > >>> >>> +#endif
> > >>> >>
> > >>> >>Why ifdef?  Isn't it safe to just always have this in?
> > >>> If no ifdef here, gcc reported a compiling warning when I compiled it
> > >>> on IA64 with CONFIG_HOTPLUG_CPU=n.
> > >>
> > >>Then you should probably go change it so that CPU_DEAD is defined on
> > >>non-smp builds, otherwise the code gets quite messy like the above :)
> > 
> > Sorry. My previous explanation is confusing. It's a link warning on ia64. On ia64, the kernel vmlinux doesn't include section .exit.text, so ld will report a link warning when a function is in section .exit.text and another function (not in .exit.text) calls the first one. When CONFIG_HOTPLUG_CPU=n, function topology_remove_dev is in section .exit.text, but its caller topology_remove_dev is not in .exit.text.
> > 
> > i386 and x86_64 kernel vmlinux does include .exit.text and discard it only when running, so there is no such warning on i386/x86_64.
> > 
> > There is no other better approach to get rid of the warning unless we change arch/ia64/kernel/vmlinux.lds.S to keep all .exit.text in kernel image.
> 
> Here is the new patch. Thank Greg.

Much nicer, thanks for the changes.  But you forgot the description and
the Signed-off-by: line so that it can be picked up :(

Care to try again?

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: Yanmin Zhang <ymzhang@unix-os.sc.intel.com>
Cc: linux-kernel@vger.kernel.org, discuss@x86-64.org,
	linux-ia64@vger.kernel.org, "Siddha,
	Suresh B" <suresh.b.siddha@intel.com>,
	"Shah, Rajesh" <rajesh.shah@intel.com>,
	"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
	yanmin.zhang@intel.com
Subject: Re: [PATCH v2:3/3]Export cpu topology by sysfs
Date: Mon, 26 Dec 2005 21:36:10 -0800	[thread overview]
Message-ID: <20051227053610.GE25886@kroah.com> (raw)
In-Reply-To: <20051226002839.A24653@unix-os.sc.intel.com>

On Mon, Dec 26, 2005 at 12:28:39AM -0800, Yanmin Zhang wrote:
> On Mon, Dec 26, 2005 at 03:38:16PM +0800, Zhang, Yanmin wrote:
> > >>-----Original Message-----
> > >>From: Greg KH [mailto:greg@kroah.com]
> > >>Sent: 2005??12??24?? 3:16
> > >>To: Zhang, Yanmin
> > >>Cc: Yanmin Zhang; linux-kernel@vger.kernel.org; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah, Rajesh;
> > >>Pallipadi, Venkatesh
> > >>Subject: Re: [PATCH v2:3/3]Export cpu topology by sysfs
> > >>
> > >>On Fri, Dec 23, 2005 at 12:03:27PM +0800, Zhang, Yanmin wrote:
> > >>> >>Can't you just use an attribute group and attach it to the cpu kobject?
> > >>> >>That would save an array of kobjects I think.
> > >>> As you know, current i386/x86_64 arch also export cache info under
> > >>> /sys/device/system/cpu/cpuX/cache. Is it clearer to export topology
> > >>> under a new directory than under cpu directly?
> > >>
> > >>No, the place in the sysfs tree you are putting this is just fine.  I'm
> > >>just saying that you do not need to create a new kobject for these
> > >>attributes.  Just use an attribute group, and you will get the same
> > >>naming, without the need for an extra kobject (and the whole array of
> > >>kobjects) at all.
> > >>
> > >>Does that make more sense?
> > Yes, indeed. Now, I used your idea and the patch became simpler. Thanks.



> > 
> > 
> > >>
> > >>> >>> +static int __cpuinit topology_cpu_callback(struct notifier_block *nfb,
> > >>> >>> +		unsigned long action, void *hcpu)
> > >>> >>> +{
> > >>> >>> +	unsigned int cpu = (unsigned long)hcpu;
> > >>> >>> +	struct sys_device *sys_dev;
> > >>> >>> +
> > >>> >>> +	sys_dev = get_cpu_sysdev(cpu);
> > >>> >>> +	switch (action) {
> > >>> >>> +		case CPU_ONLINE:
> > >>> >>> +			topology_add_dev(sys_dev);
> > >>> >>> +			break;
> > >>> >>> +#ifdef	CONFIG_HOTPLUG_CPU
> > >>> >>> +		case CPU_DEAD:
> > >>> >>> +			topology_remove_dev(sys_dev);
> > >>> >>> +			break;
> > >>> >>> +#endif
> > >>> >>
> > >>> >>Why ifdef?  Isn't it safe to just always have this in?
> > >>> If no ifdef here, gcc reported a compiling warning when I compiled it
> > >>> on IA64 with CONFIG_HOTPLUG_CPU=n.
> > >>
> > >>Then you should probably go change it so that CPU_DEAD is defined on
> > >>non-smp builds, otherwise the code gets quite messy like the above :)
> > 
> > Sorry. My previous explanation is confusing. It's a link warning on ia64. On ia64, the kernel vmlinux doesn't include section .exit.text, so ld will report a link warning when a function is in section .exit.text and another function (not in .exit.text) calls the first one. When CONFIG_HOTPLUG_CPU=n, function topology_remove_dev is in section .exit.text, but its caller topology_remove_dev is not in .exit.text.
> > 
> > i386 and x86_64 kernel vmlinux does include .exit.text and discard it only when running, so there is no such warning on i386/x86_64.
> > 
> > There is no other better approach to get rid of the warning unless we change arch/ia64/kernel/vmlinux.lds.S to keep all .exit.text in kernel image.
> 
> Here is the new patch. Thank Greg.

Much nicer, thanks for the changes.  But you forgot the description and
the Signed-off-by: line so that it can be picked up :(

Care to try again?

thanks,

greg k-h

  reply	other threads:[~2005-12-27  5:36 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-21  2:09 [PATCH v2:3/3]Export cpu topology by sysfs Yanmin Zhang
2005-12-21  2:09 ` Yanmin Zhang
2005-12-23  0:16 ` Greg KH
2005-12-23  0:16   ` Greg KH
2005-12-23  4:03 ` Zhang, Yanmin
2005-12-23  4:03   ` Zhang, Yanmin
2005-12-23 19:16   ` Greg KH
2005-12-23 19:16     ` Greg KH
2005-12-26  7:38 ` Zhang, Yanmin
2005-12-26  7:38   ` Zhang, Yanmin
2005-12-26  8:28   ` Yanmin Zhang
2005-12-26  8:28     ` Yanmin Zhang
2005-12-27  5:36     ` Greg KH [this message]
2005-12-27  5:36       ` Greg KH
2005-12-27  5:35   ` Greg KH
2005-12-27  5:35     ` Greg KH
2005-12-27 10:22 ` Zhang, Yanmin
2005-12-27 10:22   ` Zhang, Yanmin
2005-12-27 10:41   ` Yanmin Zhang
2005-12-27 10:41     ` Yanmin Zhang
2005-12-27 21:19     ` Nathan Lynch
2005-12-27 21:19       ` Nathan Lynch
2005-12-28 13:46 ` Zhang, Yanmin
2005-12-28 13:46   ` Zhang, Yanmin
2005-12-28 19:14   ` Nathan Lynch
2005-12-28 19:14     ` Nathan Lynch
2005-12-31  8:43 ` Zhang, Yanmin
2005-12-31  8:43   ` Zhang, Yanmin
2006-01-04  9:06   ` [PATCH v3]Export " Yanmin Zhang
2006-01-04  9:06     ` Yanmin Zhang
2006-01-09  5:10     ` Nathan Lynch
2006-01-09  5:10       ` Nathan Lynch
2006-01-09  6:47     ` Zhang, Yanmin
2006-01-09  6:47       ` Zhang, Yanmin
2006-01-25  2:05     ` Zhang, Yanmin
2006-01-25  2:05       ` Zhang, Yanmin
2006-01-25  2:34       ` Yanmin Zhang
2006-01-25  2:34         ` Yanmin Zhang
2006-01-26  5:11       ` Nathan Lynch
2006-01-26  5:11         ` Nathan Lynch
2006-01-09  4:51   ` [PATCH v2:3/3]Export " Nathan Lynch
2006-01-09  4:51     ` Nathan Lynch
2006-01-09  6:35 ` Zhang, Yanmin
2006-01-09  6:35   ` Zhang, Yanmin
2006-01-09 17:41 ` Russ Anderson
2006-01-09 17:41   ` Russ Anderson

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=20051227053610.GE25886@kroah.com \
    --to=greg@kroah.com \
    --cc=discuss@x86-64.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rajesh.shah@intel.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=yanmin.zhang@intel.com \
    --cc=ymzhang@unix-os.sc.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.