Re: 2.6.11-rc1-mm1

[Thomas Gleixner]

On Mon, 2005-01-17 at 18:41 -0500, Karim Yaghmour wrote:
> Thomas Gleixner wrote:
> > I know, what I have said. I said reduce the filtering to the absolute
> > minimum and do the rest in userspace.
> 
> You keep adopting the interpretation which best suits you, taking
> quotes out of context, and keep repeating things that have already
> been answered. There are limits to one's patience.

I said before: "Sorting out disabled events is the filtering you 
have to do in kernel and you should do it in the hot path or
remove the unneccecary tracepoints at compiletime." 

This is exactly what I stated above. I omitted the addon of "do the rest 
in userspace", as it was obvious enough.

> What you did is change your position twice. It's there for anyone to see.

Sorry, I didn't know that you are representing anyone.

> > The now builtin filters are defined to fit somebodys needs or idea of
> > what the user should / wants to see. They will not fit everybodys
> > needs / ideas. So we start modifying, adding and #ifdefing kernel
> > filters, which is a scary vision.
> 
> Ah, finally. Here's an actual suggestion. _IF_ you want, I'll just
> export a ltt_set_filter(*callback) and rewrite the if in
> _ltt_log_event() to:
> if ((ltt_filter != NULL) && !(&ltt_filter(event_id, event_struct, data)))
> 	return -EINVAL;
> 
> You're always welcome to do the following from anywhere in your code:
> ltt_set_filter(NULL);

Provide a hook, export it and load your filters as a module, but keep
the filters out of the mainline kernel code. 

> > Enabling and disabling events is a valid basic filter request, which
> > should live in the kernel. Anything else should go into userspace, IMO.
> 
> What you are suggesting is that a system administator that wants to
> monitor his sendmail server over a period of three weeks should
> just postprocess 1.8TB (1MB/s) of data because Thomas Gleixner didn't
> like the idea of kernel event filtering based on anything but events.

A real common scenario with a broad range of users. And everybody has to
like the idea of hardwired filters in the kernel code to make the life
of this sysadmin easier.

See above about hooks.

Maybe some simple pipe would be helpful too:
	read_stream | prefilter | buildbuffers | storeit

tglx


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