linux-kernel - Re: [PATCH 7/7] tracing: add hierarchical enabling of events

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 08 May 2009 09:11:04 +0800
From:	Li Zefan <lizf@...fujitsu.com>
To:	Steven Rostedt <rostedt@...dmis.org>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Christoph Hellwig <hch@....de>
Subject: Re: [PATCH 7/7] tracing: add hierarchical enabling of events

>> Like this:
>>
>> $ cat events/irq/enable
>> 0 irq_handler_entry
>> 0 irq_handler_exit
>> 1 softirq_entry
>> 1 softirq_exit
> 
> I thought about doing something like this, but this idea for the 
> hierarchical enabling came to me around 11pm, and I had the code written 
> by 11:15pm ;-)
> 
> Which means, I figured I would do it as simple as possible. We do have 
> "set_event" that gives you a list of enabled events. My thought was still 
> having a "1" or "0" if all are either enabled or disabled. And when it is 
> a mixture, I would have a list of enabled events.
> 
> Though, it is useful. Maybe in the future. But really, the information is 
> there, and I did not expect this to be a "what is enabled" file, but 
> instead a "I want to enable/disable all these events". In other words, I 
> was much more interested in the "write" ability than the read. But who 
> knows, maybe this will change in the future.
> 

I have no strong opinion on this. So I'm fine with it, if
no one else has objections.

>> How about:
>>
>> int set = 0;
>>
>> ...
>> set |= (1 << call->enabled);
> 
> * paranoid *
> 
>   set |= (1 << !!call->enabled);
> 
>> ...
>>
>> set == 0: '?'
>> set == 1: '0'
>> set == 2: '1'
>> set == 3: 'X'
>>
>> Will this make the code simpler? :)
>>
>> Or we can go even further:
>>
>> char result[4] = { '?', '0', '1', 'X' };
>> ...
>> buf[0] = result[set];
> 
> cute, mind sending a patch ;-)
> 

Sure. :)

>>> +	ret = ftrace_set_clr_event(command, val);
>> I think we should pass "sched:" or "sched:*", instead of "sched",
>> the comment in ftrace_set_clr_event():
>>
>>          *  <name> (no ':') means all events in a subsystem with
>>          *  the name <name> or any event that matches <name>
> 
> Yeah, I thought about it too. But writing the patch in 15 minutes, I 
> decided that a "kstrdup" was easier than adding a ":" ;-)
> 

I think we can just avoid any kstrdup() or kmalloc(). I'll send a patch.
--
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/