This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
KOSAKI Motohiro wrote:+ TP_fast_assign( + __entry->sig = (int)cprm->signr; + __entry->limit = cprm->limit; + __entry->flags = cprm->mm_flags; + __entry->retval = retval; + __assign_str(name, core_name); + ), + + TP_printk("sig=%d limit=%lu dumpable=0x%lx dump_filter=0x%lx " + "corename=\"%s\" retval=%d", + __entry->sig, __entry->limit, + __entry->flags& MMF_DUMPABLE_MASK, + (__entry->flags& MMF_DUMP_FILTER_MASK)>> + MMF_DUMP_FILTER_SHIFT, + __get_str(name), __entry->retval) +); #endif /* _TRACE_SIGNAL_H */
I don't think "limit" is userfriendly name, core_limit or core_size_limit is better? plus, we have core_pipe_limit sysctl too. (it's similar but different concept limit).
Ah, I missed it. OK, so I'll rename core_limit and add core_pipe_limit.
Hmm, perhaps, would we need a pair of core_pipe_limit and dump_count? because it limits the number of concurrently dump-to-pipe and the number is stored on dump_count. Or, maybe it is enough to trace current parameters, because if we hit the core_pipe_limit, we can see -EFBIG at retval parameter.
Thank you for pointed it out :-)
other parts looks good to me.
Thanks!
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |