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]

Message-ID: <c62985530901290539r38b5fb7fr32132782e69356c7@mail.gmail.com>
Date:	Thu, 29 Jan 2009 14:39:21 +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 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 *);

 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/