On Thu, Mar 28, 2013 at 04:52:29PM +0100, Robert Richter wrote:
> An option would be to attach the persistent events to a hosting pmu
> (e.g. 'ras' in this case) and provide the events via sysfs as already
> done by other pmus:
>
> /sys/bus/event_source/devices/ras/events/
>
On Thu, Mar 28, 2013 at 04:52:29PM +0100, Robert Richter wrote:
An option would be to attach the persistent events to a hosting pmu
(e.g. 'ras' in this case) and provide the events via sysfs as already
done by other pmus:
/sys/bus/event_source/devices/ras/events/
On 18.03.13 09:46:38, Ingo Molnar wrote:
>
> * Namhyung Kim wrote:
>
> > So my question is how can an user know which persistent events are
> > available in her system?
>
> I think we need VFS enumeration for that: directories give a high level a
> structure (allowing things like per user
On 18.03.13 09:46:38, Ingo Molnar wrote:
* Namhyung Kim namhy...@kernel.org wrote:
So my question is how can an user know which persistent events are
available in her system?
I think we need VFS enumeration for that: directories give a high level a
structure (allowing things like
On Mon, Mar 18, 2013 at 09:40:08AM +0100, Ingo Molnar wrote:
> That definitely looks interesting and desirable. It would be nice to
> have more generic/flexible semantics by using the VFS for tracing
> context discovery.
>
> That would allow 'stateful tracing', and not just in a kernel
> initiated
* Namhyung Kim wrote:
> So my question is how can an user know which persistent events are
> available in her system?
I think we need VFS enumeration for that: directories give a high level a
structure (allowing things like per user contexts) while readdir will give
list of specific
* Borislav Petkov wrote:
> From: Borislav Petkov
>
> Yeah,
>
> here's a refresh of the persistent events deal, accessing those is much
> cleaner now. Here's how:
>
> So kernel code initializes and enables the event at its convenience
> (during boot, whenever) and userspace goes and says:
>
Hi Borislav,
On Fri, 15 Mar 2013 14:06:26 +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Yeah,
>
> here's a refresh of the persistent events deal, accessing those is much
> cleaner now. Here's how:
>
> So kernel code initializes and enables the event at its convenience
> (during boot,
Hi Borislav,
On Fri, 15 Mar 2013 14:06:26 +0100, Borislav Petkov wrote:
From: Borislav Petkov b...@suse.de
Yeah,
here's a refresh of the persistent events deal, accessing those is much
cleaner now. Here's how:
So kernel code initializes and enables the event at its convenience
(during
* Borislav Petkov b...@alien8.de wrote:
From: Borislav Petkov b...@suse.de
Yeah,
here's a refresh of the persistent events deal, accessing those is much
cleaner now. Here's how:
So kernel code initializes and enables the event at its convenience
(during boot, whenever) and userspace
* Namhyung Kim namhy...@kernel.org wrote:
So my question is how can an user know which persistent events are
available in her system?
I think we need VFS enumeration for that: directories give a high level a
structure (allowing things like per user contexts) while readdir will give
list of
On Mon, Mar 18, 2013 at 09:40:08AM +0100, Ingo Molnar wrote:
That definitely looks interesting and desirable. It would be nice to
have more generic/flexible semantics by using the VFS for tracing
context discovery.
That would allow 'stateful tracing', and not just in a kernel
initiated
From: Borislav Petkov
Yeah,
here's a refresh of the persistent events deal, accessing those is much
cleaner now. Here's how:
So kernel code initializes and enables the event at its convenience
(during boot, whenever) and userspace goes and says:
sys_perf_event_open(pattr,...)
with
From: Borislav Petkov b...@suse.de
Yeah,
here's a refresh of the persistent events deal, accessing those is much
cleaner now. Here's how:
So kernel code initializes and enables the event at its convenience
(during boot, whenever) and userspace goes and says:
14 matches
Mail list logo
