linux-kernel - Re: [PATCH] tracer for sys_open()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Jan 2009 14:40:28 +0100
From:	Frédéric Weisbecker <fweisbec@...il.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	powertop ml <power@...host.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	"srostedt@...hat.com" <srostedt@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Neil Horman <nhorman@...driver.com>,
	"Kok, Auke" <auke@...-projects.org>
Subject: Re: [PATCH] tracer for sys_open() - sreadahead

2009/1/29 Frédéric Weisbecker <fweisbec@...il.com>:
> 2009/1/29 Arnaldo Carvalho de Melo <acme@...stprotocols.net>:
>> hey, hey, your patch just illustrated that we need a subtype facility.
>>
>> I'm (as all the other people in some shape or form involved in pushing
>> some sort of common tracing infrastructure into the kernel, I guess)
>> excited about more developers using what is being put in place :-)
>
>
> Indeed :-)
>
> About these subtypes. I've thought about what can be intuitive for
> developers who
> will use it.
>
> I think the struct trace_event can be reused by just adding a subtype
> event inside:
>
> + int (*find_subtype_func) (struct trace_iterator *);


Sorry: forgot the typedef there...

>
>  struct trace_event {
>        struct hlist_node       node;
>        int                     type;
>        trace_print_func        trace;
>        trace_print_func        latency_trace;
>        trace_print_func        raw;
>        trace_print_func        hex;
>        trace_print_func        binary;
> +      struct trace_event *subevent_array;
> +      find_subtype_func find_subtype;
>  };
>
> And then I shall implement an event internal hlist for each global event.
> All a tracer developer just have to do is:
>
> _ implement a general trace_event for his global event type
> _ implement each trace subevent as an array, one will have to define
> its own set of values for the types, they will
>  not conflict with those used by global event types since they are
> isolated and depend on one global event type.
> _ implement find_subtype callback. When a new trace has to be printed,
> this callback is called to find the subtype
>  value corresponding to a trace. If the tracer returns a positive
> value, the matching subevent is searched on the subevent_array
>  and the appropriate trace_print_func is called.
>  Otherwise if find_subtype is NULL or returns -EINVAL, then the
> appropriate trace_print_func of the current global event is called, as
>  usual.
>
> We can even make it recursive, letting one crazy tracer beeing able to
> have subtypes of subtypes :-)
>
> Hm? If you are ok, I shall start it.
>
>
>>> In all it was not productive to write a giant trace facility just to get
>>> sreadahead one tracer type. Now that the code works and the benefit is proven, I'm
>>> happy to see if we can work on making a decent long-term non-specialistic solution.
>>
>> That is the spirit!
>>
>> - Arnaldo
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/