twitter: linux.kernel - 26 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* [PATCH] hwmon: Add driver for intel PCI thermal subsystem - 4 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/9dfaba6224dde3ad?hl=en
* todays git regression (2.6.32-04008.g3ff6a46): lot of device mapper warnings
- 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d0cfe9f9404f1b1e?hl=en
* laptop-mode: Make flushes per-device - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d1a730d8a86ba355?hl=en
* dynamic ftrace - graph - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bfbdc48cdbe6dc9e?hl=en
* mpc85xx_edac.c: use resource_size() - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/13cf20a026d29a7f?hl=en
* perf symbols: Rename kthreads to kmaps, using another abstraction for it - 4
messages, 1 author
http://groups.google.com/group/linux.kernel/t/afd66bc3b2301117?hl=en
* acpi, apei, Document for APEI - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/4556ae33a48a31e5?hl=en
* Documentation: rw_lock lessons learned - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f143e8f1268944f9?hl=en
* cfq-iosched: reduce write depth only if sync was delayed - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/85566d72f71c5737?hl=en
* x86, msr: add support for non-contiguous cpumasks - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/822e42967bfc3ded?hl=en
* Logitech G13 driver + user-space libraries available - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/850482677042fb64?hl=en
* usb: otg: twl4030: add support for notifier - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* Fix 2.6.33 x86 regression to kgdb hw breakpoints - due to perf API changes -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b1e9093e8d9a0685?hl=en
* perf symbols: Add missing "Variables" entry to map_type__name - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/bfe825a1ad91b92c?hl=en
* x86: UV BAU interrupt vector duplicated - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2d916eee36ac5779?hl=en
* linux-next: Tree for December 11 (media/dvb/frontends) - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0e84bed4984f2109?hl=en
* acpi: don't cond_resched if irq is disabled - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/652b6acb852da6ca?hl=en

==============================================================================
TOPIC: [PATCH] hwmon: Add driver for intel PCI thermal subsystem
http://groups.google.com/group/linux.kernel/t/9dfaba6224dde3ad?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Dec 11 2009 8:40 am
From: Luca Tettamanti

On Fri, Dec 11, 2009 at 5:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, Dec 11, 2009 at 05:28:37PM +0100, Luca Tettamanti wrote:
>> On Fri, Dec 11, 2009 at 4:52 PM, Matthew Garrett <mjg@redhat.com> wrote:
>> > Recent Intel chipsets have support for a PCI device providing access
>> > to on-board thermal monitoring. Previous versions have merely used this
>> > to allow the BIOS to set trip points, but Ibex Peak documents a set of
>> > registers to read values. This driver implements an hwmon interface to
>> > read them.
>>
>> Does it plays nice with other drivers?
>> More specifically: is it possible to load the native driver and this
>> one (which I presume pokes at the same chip) at the same time?
>
> What do you mean by native driver? This is a native driver for the chip
> in question.

I mean the driver for the hwmon chip attached to I2C/SMB bus.

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

== 2 of 4 ==
Date: Fri, Dec 11 2009 8:50 am
From: Luca Tettamanti

On Fri, Dec 11, 2009 at 5:38 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, Dec 11, 2009 at 05:36:59PM +0100, Luca Tettamanti wrote:
>> On Fri, Dec 11, 2009 at 5:33 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> >> Does it plays nice with other drivers?
>> >> More specifically: is it possible to load the native driver and this
>> >> one (which I presume pokes at the same chip) at the same time?
>> >
>> > What do you mean by native driver? This is a native driver for the chip
>> > in question.
>>
>> I mean the driver for the hwmon chip attached to I2C/SMB bus.
>
> This is the hwmon chip.

Sorry, I think we're not understanding each other :)
Does the PCH samples the values directly from the probes? Or is it an
interface for the real monitoring chip (most likely the superio chip)?
In the latter case it might be possible to access directly the
monitoring hardware using another driver (e.g. w83627ehf, lm80, etc.),
thus racing against the PCI driver.
Did I make myself clear?

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

== 3 of 4 ==
Date: Fri, Dec 11 2009 9:00 am
From: Luca Tettamanti

On Fri, Dec 11, 2009 at 5:50 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, Dec 11, 2009 at 05:47:29PM +0100, Luca Tettamanti wrote:
>> Sorry, I think we're not understanding each other :)
>> Does the PCH samples the values directly from the probes? Or is it an
>> interface for the real monitoring chip (most likely the superio chip)?
>> In the latter case it might be possible to access directly the
>> monitoring hardware using another driver (e.g. w83627ehf, lm80, etc.),
>> thus racing against the PCI driver.
>> Did I make myself clear?
>
> I don't think there's any other chip. On systems using external chips,
> this PCI device will simply be disabled by the BIOS before the OS boots.

Ok, good.
The other potential issue is asus_atk0110 driver; ASUS boards have a
ACPI interface to the hwmon stuff.
Will check with my testers.

== 4 of 4 ==
Date: Fri, Dec 11 2009 9:00 am
From: Matthew Garrett

On Fri, Dec 11, 2009 at 05:47:29PM +0100, Luca Tettamanti wrote:

> Sorry, I think we're not understanding each other :)
> Does the PCH samples the values directly from the probes? Or is it an
> interface for the real monitoring chip (most likely the superio chip)?
> In the latter case it might be possible to access directly the
> monitoring hardware using another driver (e.g. w83627ehf, lm80, etc.),
> thus racing against the PCI driver.
> Did I make myself clear?

I don't think there's any other chip. On systems using external chips,
this PCI device will simply be disabled by the BIOS before the OS boots.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: todays git regression (2.6.32-04008.g3ff6a46): lot of device mapper
warnings
http://groups.google.com/group/linux.kernel/t/d0cfe9f9404f1b1e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 11 2009 8:50 am
From: "Martin K. Petersen"

>>>>> "Christian" == Christian Borntraeger <borntraeger@de.ibm.com> writes:

Christian> any news on the final fix? Do you want Heinz and me to verify
Christian> your fix on our systems?

Looking into this issue unearthed an unrelated problem with the topology
stacking algorithm that turns out to be much trickier to fix. That's
what's taking time.

Since the first bug is simply causing a warning I'm inclined to get
everything fixed up before having Jens queue a fix. Shouldn't be more
than a day or two before I have all this worked out.

--
Martin K. Petersen Oracle Linux Engineering

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

==============================================================================
TOPIC: laptop-mode: Make flushes per-device
http://groups.google.com/group/linux.kernel/t/d1a730d8a86ba355?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 11 2009 8:50 am
From: Matthew Garrett

Sorry, I seem to have screwed up the includes somehow when I rebased
this. I'm now trapped in a maze of twisty interdependencies, all
different.

==============================================================================
TOPIC: dynamic ftrace - graph
http://groups.google.com/group/linux.kernel/t/bfbdc48cdbe6dc9e?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 11 2009 8:50 am
From: Michal Simek

Steven Rostedt wrote:
> On Fri, 2009-12-11 at 16:28 +0100, Michal Simek wrote:
>> Steven Rostedt wrote:
>>> On Fri, 2009-12-11 at 15:40 +0100, Michal Simek wrote:
>>>> Steven Rostedt wrote:
>>>>> Hey, if they work and they are only in your arch, then I'm fine with
>>>>> them ;-)
>>>> yeah. There is one just small hook to recordmcount.pl. :-)
>>> I may need to give an acked-by. If I did not yet, could you send me that
>>> specific patch.
>> I sent that patches to LKML last month - you were cc'd.
>> http://lkml.org/lkml/2009/11/23/48
>
> They are probably still in the "todo" pile ;-)

:-)

>
>> You should get it in your mailbox
>>
>> That part is pretty easy. :-)
>>
>> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
>> index 090d300..b30dabd 100755
>> --- a/scripts/recordmcount.pl
>> +++ b/scripts/recordmcount.pl
>> @@ -245,6 +245,9 @@ if ($arch eq "x86_64") {
>> $ld .= " -m elf64_sparc";
>> $cc .= " -m64";
>> $objcopy .= " -O elf64-sparc";
>> +} elsif ($arch eq "microblaze") {
>> + # Microblaze calls '_mcount' instead of plain 'mcount'.
>> + $mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s_mcount\$";
>> } else {
>> die "Arch $arch is not supported with CONFIG_FTRACE_MCOUNT_RECORD";
>> }
>
> If that's all it is, then here:

yes.
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>

I don't expect it.:-)

>
>>
>>>
>>>> we will see. Currently I have small problem only with irqsoff but I
>>>> think this don't have connection with ftrace - only with lockdep I
>>>> think. :-)
>>> You have lockdep working? If you get lockdep working you should get the
>>> irqsoff tracer for free.
>> I have some problems when I turn on lockdep debug (CONFIG_DEBUG_LOCKDEP)
>> - kernel freeze for currently unknown reason.
>> I saw that some arch has some part of code in entry.S but I haven't had
>> a time to look at them - maybe needs some changes there too.
>
> Yeah, anytime you disable interrupts or enable them (including when the
> hardware does it from entering an exception), you need to call into the
> lockdep infrastructure (trace_hardiqs_on/off){_caller}.

yes that's missing.

>
>
>> As you can see below locking testsuite output looks fine but irqsoff
>> tracer freeze the kernel. Function tracer is ok.
>>
>> There could be a problem with some arch specific functions which
>> shouldn't be compiled with -pg.
>
> Does it still freeze if you don't enable the function tracer?

look below.

>
>> Any suggestions? :-)
>>
>
>
>> # cd /
>> # mkdir debug
>> # mount -t debugfs none /debug
>> # cat /debug/tracing/available_tracers
>> irqsoff function sched_switch nop
>> # echo irqsoff > /debug/tracing/current_tracer
>>
>> and kernel freeze. :-(
>
> Try it without configuring function tracer, or you could also do:

uclinux login: root
Password:
Login incorrect
uclinux login: root
Password:
# cd /
# mkdir debug
# mount -t debugfs none /debug/
# cat /debug/tracing/available_tracers
irqsoff sched_switch nop
# echo irqsoff > /debug/tracing/current_tracer

Also freeze - the problem is that low level code. I will look at it next
week.

Thanks,
Michal

>
> echo 0 > /proc/sys/ftrace_enabled
>
> That will also disable the function tracer.
>
> -- Steve
>
>

--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: mpc85xx_edac.c: use resource_size()
http://groups.google.com/group/linux.kernel/t/13cf20a026d29a7f?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Dec 11 2009 9:00 am
From: Dave Jiang

Acked-by: Dave Jiang <djiang@mvista.com>

On 12/11/2009 09:52 AM, H Hartley Sweeten wrote:
> Use resource_size().
>
> Signed-off-by: H Hartley Sweeten<hsweeten@visionengravers.com>
> Cc: Doug Thompson<dougthompson@xmission.com>
> Cc: Dave Jiang<djiang@mvista.com>
>
> ---
>
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index cf27402..adecf37 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -239,16 +239,15 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device *op,
> /* we only need the error registers */
> r.start += 0xe00;
>
> - if (!devm_request_mem_region(&op->dev, r.start,
> - r.end - r.start + 1, pdata->name)) {
> + if (!devm_request_mem_region(&op->dev, r.start, resource_size(&r),
> + pdata->name)) {
> printk(KERN_ERR "%s: Error while requesting mem region\n",
> __func__);
> res = -EBUSY;
> goto err;
> }
>
> - pdata->pci_vbase = devm_ioremap(&op->dev, r.start,
> - r.end - r.start + 1);
> + pdata->pci_vbase = devm_ioremap(&op->dev, r.start, resource_size(&r));
> if (!pdata->pci_vbase) {
> printk(KERN_ERR "%s: Unable to setup PCI err regs\n", __func__);
> res = -ENOMEM;

== 2 of 2 ==
Date: Fri, Dec 11 2009 9:00 am
From: "H Hartley Sweeten"

Use resource_size().

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Cc: Dave Jiang <djiang@mvista.com>

---

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index cf27402..adecf37 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -239,16 +239,15 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device *op,
/* we only need the error registers */
r.start += 0xe00;

- if (!devm_request_mem_region(&op->dev, r.start,
- r.end - r.start + 1, pdata->name)) {
+ if (!devm_request_mem_region(&op->dev, r.start, resource_size(&r),
+ pdata->name)) {
printk(KERN_ERR "%s: Error while requesting mem region\n",
__func__);
res = -EBUSY;
goto err;
}

- pdata->pci_vbase = devm_ioremap(&op->dev, r.start,
- r.end - r.start + 1);
+ pdata->pci_vbase = devm_ioremap(&op->dev, r.start, resource_size(&r));
if (!pdata->pci_vbase) {
printk(KERN_ERR "%s: Unable to setup PCI err regs\n", __func__);
res = -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: perf symbols: Rename kthreads to kmaps, using another abstraction for
it
http://groups.google.com/group/linux.kernel/t/afd66bc3b2301117?hl=en
==============================================================================

== 1 of 4 ==
Date: Fri, Dec 11 2009 9:00 am
From: Arnaldo Carvalho de Melo

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Using a struct thread instance just to hold the kernel space maps
(vmlinux + modules) is overkill and confuses people trying to understand
the perf symbols abstractions.

The kernel maps are really present in all threads, i.e. the kernel is a
library, not a separate thread.

So introduce the 'map_groups' abstraction and use it for the kernel
maps, now in the kmaps global variable.

It, in turn, will move, together with the threads list to the perf_file
abstraction, so that we can support multiple perf_file instances, needed
by perf diff.

Brainstormed-with: Eduardo Habkost <ehabkost@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Frédéric Weisbecker <fweisbec@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/builtin-kmem.c | 2 +-
tools/perf/util/event.c | 11 ++++---
tools/perf/util/symbol.c | 73 +++++++++++++++++++++++----------------------
tools/perf/util/symbol.h | 4 +-
tools/perf/util/thread.c | 62 +++++++++++++++++++++----------------
tools/perf/util/thread.h | 39 +++++++++++++++--------
6 files changed, 106 insertions(+), 85 deletions(-)

diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 5f20951..fe73435 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -403,7 +403,7 @@ static void __print_result(struct rb_root *root, int n_lines, int is_caller)
if (is_caller) {
addr = data->call_site;
if (!raw_ip)
- sym = thread__find_function(kthread, addr, NULL);
+ sym = map_groups__find_function(kmaps, addr, NULL);
} else
addr = data->ptr;

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 4dcecaf..ba0de90 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -254,13 +254,14 @@ void thread__find_addr_location(struct thread *self, u8 cpumode,
struct addr_location *al,
symbol_filter_t filter)
{
- struct thread *thread = al->thread = self;
+ struct map_groups *mg = &self->mg;

+ al->thread = self;
al->addr = addr;

if (cpumode & PERF_RECORD_MISC_KERNEL) {
al->level = 'k';
- thread = kthread;
+ mg = kmaps;
} else if (cpumode & PERF_RECORD_MISC_USER)
al->level = '.';
else {
@@ -270,7 +271,7 @@ void thread__find_addr_location(struct thread *self, u8 cpumode,
return;
}
try_again:
- al->map = thread__find_map(thread, type, al->addr);
+ al->map = map_groups__find(mg, type, al->addr);
if (al->map == NULL) {
/*
* If this is outside of all known maps, and is a negative
@@ -281,8 +282,8 @@ try_again:
* "[vdso]" dso, but for now lets use the old trick of looking
* in the whole kernel symbol list.
*/
- if ((long long)al->addr < 0 && thread != kthread) {
- thread = kthread;
+ if ((long long)al->addr < 0 && mg != kmaps) {
+ mg = kmaps;
goto try_again;
}
al->sym = NULL;
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7508ad..9362023 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -29,11 +29,11 @@ enum dso_origin {
};

static void dsos__add(struct list_head *head, struct dso *dso);
-static struct map *thread__find_map_by_name(struct thread *self, char *name);
+static struct map *map_groups__find_by_name(struct map_groups *self, char *name);
static struct map *map__new2(u64 start, struct dso *dso, enum map_type type);
struct symbol *dso__find_symbol(struct dso *self, enum map_type type, u64 addr);
static int dso__load_kernel_sym(struct dso *self, struct map *map,
- struct thread *thread, symbol_filter_t filter);
+ struct map_groups *mg, symbol_filter_t filter);
unsigned int symbol__priv_size;
static int vmlinux_path__nr_entries;
static char **vmlinux_path;
@@ -43,8 +43,8 @@ static struct symbol_conf symbol_conf__defaults = {
.try_vmlinux_path = true,
};

-static struct thread kthread_mem;
-struct thread *kthread = &kthread_mem;
+static struct map_groups kmaps_mem;
+struct map_groups *kmaps = &kmaps_mem;

bool dso__loaded(const struct dso *self, enum map_type type)
{
@@ -79,7 +79,7 @@ static void symbols__fixup_end(struct rb_root *self)
curr->end = roundup(curr->start, 4096);
}

-static void __thread__fixup_maps_end(struct thread *self, enum map_type type)
+static void __map_groups__fixup_end(struct map_groups *self, enum map_type type)
{
struct map *prev, *curr;
struct rb_node *nd, *prevnd = rb_first(&self->maps[type]);
@@ -102,11 +102,11 @@ static void __thread__fixup_maps_end(struct thread *self, enum map_type type)
curr->end = ~0UL;
}

-static void thread__fixup_maps_end(struct thread *self)
+static void map_groups__fixup_end(struct map_groups *self)
{
int i;
for (i = 0; i < MAP__NR_TYPES; ++i)
- __thread__fixup_maps_end(self, i);
+ __map_groups__fixup_end(self, i);
}

static struct symbol *symbol__new(u64 start, u64 len, const char *name)
@@ -364,8 +364,8 @@ out_failure:
* kernel range is broken in several maps, named [kernel].N, as we don't have
* the original ELF section names vmlinux have.
*/
-static int dso__split_kallsyms(struct dso *self, struct map *map, struct thread *thread,
- symbol_filter_t filter)
+static int dso__split_kallsyms(struct dso *self, struct map *map,
+ struct map_groups *mg, symbol_filter_t filter)
{
struct map *curr_map = map;
struct symbol *pos;
@@ -382,13 +382,13 @@ static int dso__split_kallsyms(struct dso *self, struct map *map, struct thread

module = strchr(pos->name, '\t');
if (module) {
- if (!thread->use_modules)
+ if (!mg->use_modules)
goto discard_symbol;

*module++ = '\0';

if (strcmp(self->name, module)) {
- curr_map = thread__find_map_by_name(thread, module);
+ curr_map = map_groups__find_by_name(mg, module);
if (curr_map == NULL) {
pr_debug("/proc/{kallsyms,modules} "
"inconsistency!\n");
@@ -419,7 +419,7 @@ static int dso__split_kallsyms(struct dso *self, struct map *map, struct thread
}

curr_map->map_ip = curr_map->unmap_ip = identity__map_ip;
- __thread__insert_map(thread, curr_map);
+ map_groups__insert(mg, curr_map);
++kernel_range;
}

@@ -440,7 +440,7 @@ discard_symbol: rb_erase(&pos->rb_node, root);

static int dso__load_kallsyms(struct dso *self, struct map *map,
- struct thread *thread, symbol_filter_t filter)
+ struct map_groups *mg, symbol_filter_t filter)
{
if (dso__load_all_kallsyms(self, map) < 0)
return -1;
@@ -448,13 +448,13 @@ static int dso__load_kallsyms(struct dso *self, struct map *map,
symbols__fixup_end(&self->symbols[map->type]);
self->origin = DSO__ORIG_KERNEL;

- return dso__split_kallsyms(self, map, thread, filter);
+ return dso__split_kallsyms(self, map, mg, filter);
}

size_t kernel_maps__fprintf(FILE *fp)
{
size_t printed = fprintf(fp, "Kernel maps:\n");
- printed += thread__fprintf_maps(kthread, fp);
+ printed += map_groups__fprintf_maps(kmaps, fp);
return printed + fprintf(fp, "END kernel maps\n");
}

@@ -745,7 +745,7 @@ out:
}

static int dso__load_sym(struct dso *self, struct map *map,
- struct thread *thread, const char *name, int fd,
+ struct map_groups *mg, const char *name, int fd,
symbol_filter_t filter, int kernel, int kmodule)
{
struct map *curr_map = map;
@@ -849,7 +849,7 @@ static int dso__load_sym(struct dso *self, struct map *map,
snprintf(dso_name, sizeof(dso_name),
"%s%s", self->short_name, section_name);

- curr_map = thread__find_map_by_name(thread, dso_name);
+ curr_map = map_groups__find_by_name(mg, dso_name);
if (curr_map == NULL) {
u64 start = sym.st_value;

@@ -868,7 +868,7 @@ static int dso__load_sym(struct dso *self, struct map *map,
curr_map->map_ip = identity__map_ip;
curr_map->unmap_ip = identity__map_ip;
curr_dso->origin = DSO__ORIG_KERNEL;
- __thread__insert_map(kthread, curr_map);
+ map_groups__insert(kmaps, curr_map);
dsos__add(&dsos__kernel, curr_dso);
} else
curr_dso = curr_map->dso;
@@ -1094,7 +1094,7 @@ int dso__load(struct dso *self, struct map *map, symbol_filter_t filter)
dso__set_loaded(self, map->type);

if (self->kernel)
- return dso__load_kernel_sym(self, map, kthread, filter);
+ return dso__load_kernel_sym(self, map, kmaps, filter);

name = malloc(size);
if (!name)
@@ -1180,7 +1180,7 @@ out:
return ret;
}

-static struct map *thread__find_map_by_name(struct thread *self, char *name)
+static struct map *map_groups__find_by_name(struct map_groups *self, char *name)
{
struct rb_node *nd;

@@ -1228,7 +1228,7 @@ static int dsos__set_modules_path_dir(char *dirname)
(int)(dot - dent->d_name), dent->d_name);

strxfrchar(dso_name, '-', '_');
- map = thread__find_map_by_name(kthread, dso_name);
+ map = map_groups__find_by_name(kmaps, dso_name);
if (map == NULL)
continue;

@@ -1281,7 +1281,7 @@ static struct map *map__new2(u64 start, struct dso *dso, enum map_type type)
return self;
}

-static int thread__create_module_maps(struct thread *self)
+static int map_groups__create_module_maps(struct map_groups *self)
{
char *line = NULL;
size_t n;
@@ -1338,7 +1338,7 @@ static int thread__create_module_maps(struct thread *self)
dso->has_build_id = true;

dso->origin = DSO__ORIG_KMODULE;
- __thread__insert_map(self, map);
+ map_groups__insert(self, map);
dsos__add(&dsos__kernel, dso);
}

@@ -1353,7 +1353,8 @@ out_failure:
return -1;
}

-static int dso__load_vmlinux(struct dso *self, struct map *map, struct thread *thread,
+static int dso__load_vmlinux(struct dso *self, struct map *map,
+ struct map_groups *mg,
const char *vmlinux, symbol_filter_t filter)
{
int err = -1, fd;
@@ -1387,14 +1388,14 @@ static int dso__load_vmlinux(struct dso *self, struct map *map, struct thread *t
return -1;

dso__set_loaded(self, map->type);
- err = dso__load_sym(self, map, thread, self->long_name, fd, filter, 1, 0);
+ err = dso__load_sym(self, map, mg, self->long_name, fd, filter, 1, 0);
close(fd);

return err;
}

static int dso__load_kernel_sym(struct dso *self, struct map *map,
- struct thread *thread, symbol_filter_t filter)
+ struct map_groups *mg, symbol_filter_t filter)
{
int err;
bool is_kallsyms;
@@ -1404,7 +1405,7 @@ static int dso__load_kernel_sym(struct dso *self, struct map *map,
pr_debug("Looking at the vmlinux_path (%d entries long)\n",
vmlinux_path__nr_entries);
for (i = 0; i < vmlinux_path__nr_entries; ++i) {
- err = dso__load_vmlinux(self, map, thread,
+ err = dso__load_vmlinux(self, map, mg,
vmlinux_path[i], filter);
if (err > 0) {
pr_debug("Using %s for symbols\n",
@@ -1420,12 +1421,12 @@ static int dso__load_kernel_sym(struct dso *self, struct map *map,
if (is_kallsyms)
goto do_kallsyms;

- err = dso__load_vmlinux(self, map, thread, self->long_name, filter);
+ err = dso__load_vmlinux(self, map, mg, self->long_name, filter);
if (err <= 0) {
pr_info("The file %s cannot be used, "
"trying to use /proc/kallsyms...", self->long_name);
do_kallsyms:
- err = dso__load_kallsyms(self, map, thread, filter);
+ err = dso__load_kallsyms(self, map, mg, filter);
if (err > 0 && !is_kallsyms)
dso__set_long_name(self, strdup("[kernel.kallsyms]"));
}
@@ -1508,7 +1509,7 @@ size_t dsos__fprintf_buildid(FILE *fp)
__dsos__fprintf_buildid(&dsos__user, fp));
}

-static int thread__create_kernel_map(struct thread *self, const char *vmlinux)
+static int map_groups__create_kernel_map(struct map_groups *self, const char *vmlinux)
{
struct map *kmap;
struct dso *kernel = dso__new(vmlinux ?: "[kernel.kallsyms]");
@@ -1533,7 +1534,7 @@ static int thread__create_kernel_map(struct thread *self, const char *vmlinux)
sizeof(kernel->build_id)) == 0)
kernel->has_build_id = true;

- __thread__insert_map(self, kmap);
+ map_groups__insert(self, kmap);
dsos__add(&dsos__kernel, kernel);
dsos__add(&dsos__user, vdso);

@@ -1607,23 +1608,23 @@ int symbol__init(struct symbol_conf *conf)

elf_version(EV_CURRENT);
symbol__priv_size = pconf->priv_size;
- thread__init(kthread, 0);
+ map_groups__init(kmaps);

if (pconf->try_vmlinux_path && vmlinux_path__init() < 0)
return -1;

- if (thread__create_kernel_map(kthread, pconf->vmlinux_name) < 0) {
+ if (map_groups__create_kernel_map(kmaps, pconf->vmlinux_name) < 0) {
vmlinux_path__exit();
return -1;
}

- kthread->use_modules = pconf->use_modules;
- if (pconf->use_modules && thread__create_module_maps(kthread) < 0)
+ kmaps->use_modules = pconf->use_modules;
+ if (pconf->use_modules && map_groups__create_module_maps(kmaps) < 0)
pr_debug("Failed to load list of modules in use, "
"continuing...\n");
/*
* Now that we have all the maps created, just set the ->end of them:
*/
- thread__fixup_maps_end(kthread);
+ map_groups__fixup_end(kmaps);
return 0;
}
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 17003ef..6e1da1e 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -113,8 +113,8 @@ size_t kernel_maps__fprintf(FILE *fp);

int symbol__init(struct symbol_conf *conf);

-struct thread;
-struct thread *kthread;
+struct map_groups;
+struct map_groups *kmaps;
extern struct list_head dsos__user, dsos__kernel;
extern struct dso *vdso;

twitter

Friday, December 11, 2009

linux.kernel - 26 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts