Hello Roman, Roman Zippel wrote: > On Sat, 15 Jan 2005, Karim Yaghmour wrote: >>In addition, and this is a very important issue, quite a few >>kernel developers mistook LTT for a kernel debugging tool, which >>it was never meant to be. When, in fact, if you ask those who have >>looked at using it for that purpose (try Marcelo or Andrea) you will >>see that they didn't find it to be appropriate for them. And >>rightly so, it was never meant for that purpose. Even lately, when >>I suggested Ingo try using relayfs instead of his custom tracing >>code for his preemption work, he looked at it and said that it >>wasn't suited, but would consider reusing parts of it if it were >>in the kernel. > > Well, that's really a core problem. We don't want to duplicate > infrastructure, which practically does the same. So if relayfs isn't > usable in this kind of situation, it really raises the question whether > relayfs is usable at all. We need to make relayfs generally usable, > otherwise it will join the fate of devfs.
Hmm, coming from you I will take this is a pretty strong endorsement for what I was suggesting earlier: provide a basic buffering mode in relayfs to be used in kernel debugging. However, it must be understood that this is separate from the existing modes and ltt, for example, could not use such a basic infrastructure. If this is ok with you, and no one wants to complain too loudly about this, I will go ahead and add this to our to-do list for relayfs. Karim -- Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
