From: Shaohui Zheng on
On Tue, May 18, 2010 at 12:27:05AM -0700, Dave Hansen wrote:
> On Tue, 2010-05-18 at 13:41 +0800, Shaohui Zheng wrote:
> > On Thu, May 13, 2010 at 11:49:38AM -0700, Dave Hansen wrote:
> > the configfs was introduced in 2005, you can refer to http://lwn.net/Articles/148973/.
> >
> > I enabled the configfs, and I see that the configfs is not so popular as we expected,
> > I mount configfs to /sys/kernel/config, I get an empty directory. It means that nobody is
> > using this file system, it is an interesting thing, is it means that configfs is deprecated?
> > If so, it might not be nessarry to develop a configfs interface for hotplug.
>
> Uh, deprecated? What would make you think that? It does look like the
> users are a we bit obscure, but that's a bit far from deprecated.
>
> > Dave & Greg,
> > Can you provide an exmample to use configfs as interface in Linux kernel, I want to get
> > a live demo, thanks.
>
> Heh. There are some great tools out there called cscope and grep. I
> have them on my system and I bet you can get them on yours too.
>
> That said, you're right. There don't seem to be a ton of users of it
> these days. But, the LWN article you referenced also pointed to at
> least one user. So, please try and put a wee bit of effort into it.

I am trying to put a few efforts on it, and we hope to support both sysfs and configfs.

because of the history reason, sysfs is more popular. I bet that only vew few users know
configfs, so sysfs is still the prefered way.

>
> Maybe configfs isn't the way to go. I just think extending the 'probe'
> file is a bad idea, especially in the way your patch did it. I'm open
> to other alternatives. Since this is only for testing, perhaps debugfs
> applies better. What other alternatives have you explored? How about a
> Systemtap set to do it? :)
>
> -- Dave

Did not try other alternatives until now. Thanks for Dave's suggestions, Systemtap and debugfs
seems to be good methods, too.


--
Thanks & Regards,
Shaohui

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaohui Zheng on
On Tue, May 18, 2010 at 04:44:32PM +0900, Paul Mundt wrote:
> On Tue, May 18, 2010 at 01:41:21PM +0800, Shaohui Zheng wrote:
> > On Thu, May 13, 2010 at 11:49:38AM -0700, Dave Hansen wrote:
> > > On Thu, 2010-05-13 at 11:15 -0700, Greg KH wrote:
> > > > > echo "physical_address=0x40000000 numa_node=3" > memory/probe
> > > > >
> > > > > I'd *GREATLY* prefer that over this new syntax. The existing mechanism
> > > > > is obtuse enough, and the ',3' makes it more so.
> > > > >
> > > > > We should have the code around to parse arguments like that, too, since
> > > > > we use it for the boot command-line.
> > > >
> > > > If you are going to be doing something like this, please use configfs,
> > > > that is what it is designed for, not sysfs.
> > >
> > > That's probably a really good point, especially since configfs didn't
> > > even exist when we made this 'probe' file thingy. It never was a great
> > > fit for sysfs anyway.
> > >
> > > -- Dave
> >
> > the configfs was introduced in 2005, you can refer to http://lwn.net/Articles/148973/.
> >
> > I enabled the configfs, and I see that the configfs is not so popular as we expected,
> > I mount configfs to /sys/kernel/config, I get an empty directory. It means that nobody is
> > using this file system, it is an interesting thing, is it means that configfs is deprecated?
> > If so, it might not be nessarry to develop a configfs interface for hotplug.
> >
> configfs is certainly not deprecated, but there are also not that many
> users of it at present. dlm/ocfs2 were the first users as far as I
> recall, and netconsole as well. The fact you have an empty directory just
> indicates that you don't have support for any of these enabled.
>
> Note that there are also a lot of present-day sysfs and debugfs users
> that could/should be converted to configfs but haven't quite gotten there
> yet. In the sysfs case abuses are hard to rollback once they've made
> become part of the ABI, but that's not grounds for continuing sysfs abuse
> once cleaner methods become available. Many of the sysfs abuses were
> implemented before configfs existed.
>
> You can also find usage guidelines and example implementations in
> Documentation/filesystems/configfs, which should give you a pretty good
> idea of whether it's a good interface fit for your particular problem or
> not.
>
> These days sysfs seems to be the new procfs. It certainly helps to put a
> bit of planning in to the interface before you're invariably stuck with
> an ABI that's barely limping along.

Paul,
Thanks for the clear explanation for configfs, and I kown the importance of the configfs now.
the cpu/memory probe is just an interface, we care more about whether the feature works, but the
interface implemented by sysfs or configfs, it is not important. Different paths, the same objective.
Both are for us.

we follow up the style of the majority, we also accept the feedbacks from the community. I did not
how many efforts costs, but I am trying.

--
Thanks & Regards,
Shaohui

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andi Kleen on

>
> Maybe configfs isn't the way to go. I just think extending the 'probe'
> file is a bad idea, especially in the way your patch did it. I'm open
> to other alternatives. Since this is only for testing, perhaps debugfs
> applies better. What other alternatives have you explored? How about a
> Systemtap set to do it? :)

First this is a debugging interface. It doesn't need to have the
most pretty interface in the world, because it will be only used for
QA by a few people.

Requiring setting parameters in two different file systems doesn't
sound that appealing to me.

systemtap for configuration also doesn't seem right.

I liked Dave's earlier proposal to do a command line parameter like interface
for "probe". Perhaps that can be done. It shouldn't need a lot of code.

In fact there are already two different parser libraries for this:
lib/parser.c and lib/params.c. One could chose the one that one likes
better :-)

Anything that needs a lot of code is a bad idea for this I think.
A simple parser using one of the existing libraries should be simple
enough though.

Again it's just a QA interface, not the next generation of POSIX.

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Shaohui Zheng on
On Fri, May 14, 2010 at 02:49:28PM +0900, Paul Mundt wrote:
> On Thu, May 13, 2010 at 08:14:57PM +0800, Shaohui Zheng wrote:
> > hotplug emulator: support cpu probe/release in x86
> >
> > Add cpu interface probe/release under sysfs for x86. User can use this
> > interface to emulate the cpu hot-add process, it is for cpu hotplug
> > test purpose. Add a kernel option CONFIG_ARCH_CPU_PROBE_RELEASE for this
> > feature.
> >
> > This interface provides a mechanism to emulate cpu hotplug with software
> > methods, it becomes possible to do cpu hotplug automation and stress
> > testing.
> >
> At a quick glance, is this really necessary? It seems like you could
> easily replace most of this with a CPU notifier chain that takes care of
> the node handling. See for example how ppc64 manages the CPU hotplug/numa
> emulation case in arch/powerpc/mm/numa.c. arch_register_cpu() just looks
> like some topology hack for ACPI, it would be nice not to perpetuate that
> too much.

Paul,
When we reivew the possible solutions for the emulator, we already do some researching
for ppc hotplug interface, I did not has ppc background, so it is hard for me to understand
all the details, but we get clues indeed, so you see the emulator today.

We are *NOT* expecting to find simple way to probe a CPU, we are trying to emulate the
behavior with software methods, we expect the same result when we do same operation on real
hardware and emualtor. That is the reason why we did not selelct CPU notifier chain, you can
see the CPU probe process is almost the same with CPU physical hot-add, the only difference
is that some functions are replaced with a '_emu' suffix, these '_emu' function has the same
function with the old one, but it does not refer to any acpi_handle data since the hot-add
event is fake.

for exmaple:
register_cpu & register_cpu_emu
arch_register_cpu & arch_register_cpu_emu
acpi_map_lsapic & acpi_map_lsapic_emu

the nid and apic_id are parsed from the acpi_handle, but for a fake hot-add, we does not
has such data, so we delete the parser code and replace them with a parameter.

I believe you method can success probe a CPU, but it is obvious different with the CPU hot-add
process, it has the different behavior with the real hardware, it is not expect. that is the failure
of the emulation.

ppc does not care about the ACPI data, that is the reason why it seems to be simple.

--
Thanks & Regards,
Shaohui

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Hansen on
On Tue, 2010-05-18 at 10:55 +0200, Andi Kleen wrote:
> I liked Dave's earlier proposal to do a command line parameter like interface
> for "probe". Perhaps that can be done. It shouldn't need a lot of code.

After looking at the code, configfs doesn't look to me like it can be
done horribly easily. It takes a least a subsystem and then a few
structures to get things up and running. There also doesn't appear to
be a good subsystem to plug into.

> In fact there are already two different parser libraries for this:
> lib/parser.c and lib/params.c. One could chose the one that one likes
> better :-)

Agreed. But, I do see why Greg is suggesting configfs here.
Superficially, it seems like a good configfs fit, but I think configfs
is only a good fit when you need to cram a _bunch_ of stuff into a _new_
interface. Here, we have a relatively tiny amount of data that has half
of what it needs from an existing interface.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/