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
| ||
|
Date: Mon, 24 Nov 2008 11:58:40 -0500 (EST) From: Steven Rostedt <rostedt@...dmis.org> To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> cc: Christoph Hellwig <hch@...radead.org>, ltt-dev@...ts.casi.polymtl.ca, Zhaolei <zhaolei@...fujitsu.com>, Lai Jiangshan <laijs@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>, Sam Ravnborg <sam@...nborg.org> Subject: Re: LTTng kernel integration roadmap, update On Mon, 24 Nov 2008, Mathieu Desnoyers wrote: > > The key idea behind this is to answer to Thomas Gleixner concerns, who > supports that a tracer should output data in text-format only so it can > be used with tools kernel developers have on their system, like "cat". > > However, getting data out of the kernel efficiently simply cannot be > done with such approach. Therefore, LTTng needs its own userspace tools > to splice the data out of the kernel efficiently. Another tool is used > to pretty-print the binary data into text. > > Then the problem becomes : we have to make the userspace tool easy > enough to deploy so even Linus can find and use it. ;) > > But indeed, the trace buffers are versioned, so if the format changes > between kernel versions, the userspace tools will detect it and the user > will know it must update its tools. So it's not really a problem there. > > The question that prevails is therefore : should we ship userspace > binary with the kernel tree at all ? And if yes, how should the resuting > executables be packaged and deployed ? Should it be installed in the > system along with kernel modules or should it be populated into a > filesystem populated by kernelspace ? > > Or is it better to do as we have always done and keep the userspace > tools separated from the kernel tree ? I say keep the user space tools separate as much as possible. What about having a meta-data file for all binary files. This meta-data could explain the format that is read. Big endian, little endian, the fields and offsets, the event ids etc. This way we will not need a "version" file, which means absolutely nothing if you do not know what comes with that version. Any tool could look at the meta-data file and figure out what is in the buffers. -- Steve -- 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/
Powered by blists - more mailing lists