relayfs-devel — Discussion of relayfs and relayfs applications

[relayfs-devel] 加入 yue lei 的 Windows Live 网络

[Windows L. <req...@li...>]

加入 yue lei 的 Windows Live 网络查看邀请<http://cid-0EF2C2AE761DDD33.profile.live.com/messages/invitations.aspx?emailt=8db24ced5e88fa0c1%3akuYcEqCVHx%2fW1Pr6z5AMouNTas3yuMLRjzlxKHB9hDvriZjszYtiXf%2bkVi2bV1NXQqnNiZFXa0Sa%2b1qw5qdLlOKP1LXqxP95&idsToken=CStz9DVwa%21LuhJc1YEs1GGsR1Z6kJKqsv2OW3Byh%21Sm8DNXSHmFuGvqN7XNj%2a9MX%21RikxHY2hgjE%2ajkc7c6Kv0sW18UxsTC%21aXraWxFfFW17bRL4SsGEbX2K5%2a%21l46IrTzh5HzUz%2axAsRRKFmyKXWqL%21zCkZ>查看个人资料<http://cid-5B96FB6B3D8A90E3.profile.live.com/>"接受此邀请后，你们将出现在彼此的联机个人资料中，并且可以使用 Windows Live Messenger 聊天。"更改谁可以向您发送邀请和请求<http://profile.live.com/Communication>Microsoft 尊重您的隐私，请阅读我们的联机隐私声明以了解详细信息。<http://g.msn.com/2privacy/zhcn>

[relayfs-devel] Using LTT on ARM and 2.4.19

[Quenten T. <qu...@gm...>]

Hi,

I've been trying to install LTT on my embedded stargate platform (ARM)
which is running linux-2.4.19.

It looks as though ARM architectures are only supported from 0.9.6,
however, from this release on, it seems as though we need to have
relayfs installed for the daemontrace to run. However relayfs appears
to require linux installs later than 2.5. We found a backport patch of
relayfs to 2.4.26, but couldnt get it to work with 2.4.19.

This leads me to suspect that it may not be possible to run LTT on my
system, since its ARM, but also only 2.4.19.

Is this the case? Or should I persist?

Cheers,
Quenten Thomas

PS Apologies if this email reaches you twice. I wasnt sure if the
mailing list is still alive.

[relayfs-devel] =?iso-2022-jp?b?GyRCIiMkKkxkJCQ5ZyRvJDskTjdvGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?=

[<kom...@ya...>]

お問い合わせ有難うございます。
relayfs-devel様の今回ご希望では、2ショットコミュニティ対応の即会い広場が良いでしょう。

relayfs-devel様の希望に沿った方を、ご紹介できる無料メールをお届けします。
タイプ・目的・待ち合わせ日時を入力して、今すぐ即会いＯＫの新たな出会いを
お楽しみ下さい。

こちらのページ内にて紹介メールを取得できる優先WEBを設けました。
http://www.u-l-tra.com/soku126 にてメール私書箱とパスワードが取得が可能です。

この私書籍について少しご案内いたします。

まず私書籍は作成も維持も解約も無料です。
私書籍へ届いたメッセージは作成時に送信されたメールアドレスでいつでも
確認が出来きて、パソコンのほかに携帯でも確認が可能です。

女性と一対一で秘密の連絡を取り合うための私書籍となっていまして、
これから紹介できる女性もすでに私書籍を獲得済みで、とても便利なので、
今のうちに作っておいて損はありません。

宜しくお願いします。
何かありましたら、私、中込まで。
（お問い合わせ・連絡先はこちらに http://www.u-l-tra.com/soku126 ）

[relayfs-devel] RE: relayfs-devel digest, Vol 1 #15 - 2 msgs

[yue l. <che...@ho...>]

anyone know it ??
ijust want you help..
please help me ..
please...

and i want know how the "Problems trying to insert klog-mod.ko module" 
author resolve his problem??

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/  

[relayfs-devel] how to let the klog run??

[yue l. <che...@ho...>]

(1)i can't use klog in the kernal 2.6.14
and i want to know how to use the klog
from the http://relayfs.sourceforge.net/examples.html#klog_text 
"
To use klog, you'll need to apply a small patch, klog.patch, found in the 
relay-apps tarball and say 'y' to 'klog debugging functions' in the 'kernel 
hacking' config section. This will make two functions available for logging 
from anywhere within the kernel or kernel modules: 

"
(2)please tell me in detail what can i do in kernal 2.6.14 
(3)how to use the klog.patch ,please tell me in detail command ..
(4)and i can't find the klog.h in linux in kernal 2.6.14 and 2.6.16
thank you advance.

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  

[relayfs-devel] how to let the klog run??

[yue l. <che...@ho...>]

(1)i can't use klog in the kernal 2.6.14
and i want to know how to use the klog
from the http://relayfs.sourceforge.net/examples.html#klog_text 
"
To use klog, you'll need to apply a small patch, klog.patch, found in the 
relay-apps tarball and say 'y' to 'klog debugging functions' in the 'kernel 
hacking' config section. This will make two functions available for logging 
from anywhere within the kernel or kernel modules: 

"
(2)please tell me in detail what can i do in kernal 2.6.14 
(3)how to use the klog.patch ,please tell me in detail command ..
(4)and i can't find the klog.h in linux in kernal 2.6.14 and 2.6.16
thank you advance.

_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。  http://www.hotmail.com  

Re: [relayfs-devel] no output

[Tom Z. <za...@us...>]

Tim Cullen writes:
 > When people are trying to relay a problem their having to me, I always ask for the console output so I can see exactly what their typing. So I thought this may be of interest to you.
 >  
 >  As you can see klog claims to have processed one sub-buffer, while the length of the cpu0 file is 0. Previously when I was generating output via the test-mod.ko module. the file cpu0 in this same directory would end up being 2700+ bytes after I hit ctrl-c and the output generated  by test-mod.ko would be in the that.
 >  
 >  Anyway, maybe that helps, maybe it doesn't.
 >  

OK, I can't think of anything else that might be the problem - can you
send me the code or some code that will reproduce the problem?  I'll
take a look at it later today.

Thanks,

Tom

Re: [relayfs-devel] no output

[Tim C. <tim...@ya...>]

When people are trying to relay a problem their having to me, I always ask for the console output so I can see exactly what their typing. So I thought this may be of interest to you.
 
 As you can see klog claims to have processed one sub-buffer, while the length of the cpu0 file is 0. Previously when I was generating output via the test-mod.ko module. the file cpu0 in this same directory would end up being 2700+ bytes after I hit ctrl-c and the output generated  by test-mod.ko would be in the that.
 
 Anyway, maybe that helps, maybe it doesn't.
 
 tim
 
darkstar # ./klog
 Creating channel with 4 sub-buffers of size 262144.
 Logging... Press Control-C to stop
 summary:
   cpu 0:
     1 sub-buffers processed
     1 max backlog
 
 darkstar # pwd
 /home/tcullen/src/relay-apps/examples/klog
 
 darkstar # ls -l
 total 108
 -rw-r--r--  1 tcullen users   297 Jan 21 13:28 Makefile
 -rw-r--r--  1 tcullen users   597 Nov  4 01:47 README
 -rw-r--r--  1 root    root      0 Jan 21 23:34 cpu0
 -rwxr-xr-x  1 tcullen users 15378 Jan 21 13:28 klog*
 -rw-r--r--  1 tcullen users 15266 Nov  1 16:37 klog-mod.c
 -rw-r--r--  1 tcullen users  9987 Jan 21 13:28 klog-mod.ko
 -rw-r--r--  1 tcullen users   429 Jan 21 13:28 klog-mod.mod.c
 -rw-r--r--  1 tcullen users  1460 Jan 21 13:28 klog-mod.mod.o
 -rw-r--r--  1 tcullen users  9124 Jan 21 13:28 klog-mod.o
 -rw-r--r--  1 tcullen users 12598 Nov  1 14:56 klog.c
 -rw-r--r--  1 tcullen users  1184 Nov  1 19:28 test-mod.c
 -rw-r--r--  1 tcullen users  1954 Jan 21 13:28 test-mod.ko
 -rw-r--r--  1 tcullen users   429 Jan 21 13:28 test-mod.mod.c
 -rw-r--r--  1 tcullen users  1460 Jan 21 13:28 test-mod.mod.o
 -rw-r--r--  1 tcullen users  1092 Jan 21 13:28 test-mod.o
 
 darkstar # cat ./cpu0
 darkstar #
 
Tom Zanussi <za...@us...> wrote: Tim Cullen writes:
 > I suspose thats possible. "ps ax" shows them as at least being started, and the very first thing they do is call klog_printk. The thread routine looks like this:
 >  
 >  static void tm_thread( void *arg )
 >  {
 >      klog_printk( "hello from thread %d\n",(int)arg );
 >      while( 1 ) {
 >          set_current_state( TASK_INTERRUPTIBLE );
 >          schedule_timeout( 5 * HZ );
 >      }
 >  }
 >  
 >  So one would expect that the klog_printk call would run, if indeed the thread gets run at all.
 >  

Are you just doing that one klog_printk()?  The output won't be seen
by the daemon until a sub-buffer fills up or the buffer is flushed
when you Ctrl-C to stop the daemon.  You don't see any output even
after you stop the daemon?

I also wonder why even a printk() wouldn't be showing up, strange.

Tom


 >  tim
 > 
 > Tom Zanussi  wrote: Tim Cullen writes:
 >  > Hi Tom
 >  >   
 > > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >  >   
 > > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 >  > 
 >  >   very confusing...
 >  >   
 > 
 > Hmm, could it be possible that the kernel thread doesn't actually run?
 > It sounds like the printk() or klog_printk() calls may not be getting
 > executed for some reason...
 > 
 > Tom
 > 
 >  >   tim
 >  >   
 >  > Tom Zanussi  wrote:  Tim Cullen writes:
 > > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone have ideas whats going on?
 >  >  >  
 >  > 
 >  > Hi,
 >  > 
 >  > Is the klog daemon running when the kernel thread is calling
 >  > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 >  > 
 >  > The reason logging doesn't happen if the daemon isn't running is that
 >  > the klog handler defined in klog-mod.c doesn't actually call
 >  > relay_write() unless 'logging' is true, and 'logging' isn't true until
 >  > the daemon tells it to turn logging on when it starts up, the idea
 >  > being that you normally wouldn't want to log anything unless there's a
 >  > reader to drain the channel.
 >  > 
 >  > Hope that helps,
 >  > 
 >  > Tom
 >  > 
 >  > 
 >  > 
 >  > 
 >  > 
 >  >   
 >  > ---------------------------------
 >  >  
 >  >  What are the most popular cars?  Find out at Yahoo! AutosHi Tom
 >   
 > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >   
 > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 > 
 >   very confusing...
 >   
 >   tim
 >   
 > Tom Zanussi  wrote:  Tim Cullen writes:
 > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread!
 >  >  _create 
 >  >  the output never shows up anywhere. Anyone have ideas whats going on?
 >  >  
 > 
 > Hi,
 > 
 > Is the klog daemon running when the kernel thread is calling
 > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 > 
 > The reason logging doesn't happen if the daemon isn't running is that
 > the klog handler defined in klog-mod.c doesn't actually call
 > relay_write() unless 'logging' is true, and 'logging' isn't true until
 > the daemon tells it to turn logging on when it starts up, the idea
 > being that you normally wouldn't want to log anything unless there's a
 > reader to drain the channel.
 > 
 > Hope that helps,
 > 
 > Tom
 > 
 > 
 > 
 > 
 > 
 >  >   
 > 
 > ---------------------------------
 >  
 >  
 >  > What are the most popular cars?  Find out at Yahoo! Autos
 > 
 > -- 
 > Regards,
 > 
 > Tom Zanussi 
 > IBM Linux Technology Center/RAS
 > 
 > 
 >   
 > ---------------------------------
 > Yahoo! Photos – Showcase holiday pictures in hardcover
 >  Photo Books. You design it and we’ll bind it!I suspose thats possible. "ps ax" shows them as at least being started, and the very first thing they do is call klog_printk. The thread routine looks like this:
 
 static void tm_thread( void *arg )
 {
     klog_printk( "hello from thread %d\n",(int)arg );
     while( 1 ) {
         set_current_state( TASK_INTERRUPTIBLE );
         schedule_timeout( 5 * HZ );
     }
 }
 
 So one would expect that the klog_printk call would run, if indeed the thread gets run at all.
 
 tim

Tom Zanussi <za...@us...> wrote: Tim Cullen writes:
 > Hi Tom
 >   
 > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-a
 >  pps
 > tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >   
 > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 > 
 >   very confusing...
 >   

Hmm, could it be possible that the kernel thread doesn't actually run?
It sounds like the printk() or klog_printk() calls may not be getting
executed for some reason...

Tom

 >   tim
 >   
 > Tom Zanussi  wrote:  Tim Cullen writes:
 > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone hav
 >  e ideas
 >  whats going on?
 >  >  
 > 
 > Hi,
 > 
 > Is the klog daemon running when the kernel thread is calling
 > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 > 
 > The reason logging doesn't happen if the daemon isn't running is that
 > the klog handler defined in klog-mod.c doesn't actually call
 > relay_write() unless 'logging' is true, and 'logging' isn't true until
 > the daemon tells it to turn logging on when it starts up, the idea
 > being that you normally wouldn't want to log anything unless there's a
 > reader to drain the channel.
 > 
 > Hope that helps,
 > 
 > Tom
 > 
 > 
 > 
 > 
 > 
 >   
 > ---------------------------------
 >  
 >  What are the most popular cars?  Find out at Yahoo! AutosHi Tom
  
 Guess I forgot to mention that the klog daemon is 
 >  running.
 > Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
  
 On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.

  very confusing...
  
  tim
  
Tom Zanussi <za...@us...> wrote:  Tim Cullen writes:
 > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread!
 >  _create 
 >  the output never shows up anywhere. Anyone have ideas whats going on?
 >
 >  ; 
 >  

Hi,

Is the klog daemon running when the kernel thread is calling
klog_printk()?  If the klog daemon isn't running, nothing gets logged.

The reason logging doesn't happen if the daemon isn't running is that
the klog handler defined in klog-mod.c doesn't actually call
relay_write() unless 'logging' is true, and 'logging' isn't true until
the daemon tells it to turn logging on when it starts up, the idea
being that you normally wouldn't want to log anything unless there's a
reader to drain the channel.

Hope that helps,

Tom





 >   

---------------------------------
 
 
 > What are the most popular cars?  Find out at Yahoo! Autos

-- 
Regards,

Tom Zanussi 
IBM 
 >  Linux
 >  Technology Center/RAS


 >   

---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 
 > Photo Books. You design it and we’ll bind it!
-- 
Regards,

Tom Zanussi 
IBM Linux Technology Center/RASN¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰ÜŒ¨º
Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£ 塧m…éÞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âž a{› å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­þÇ¥rg–y$‰õÓ~7Ù¸môãΝjõÛ^¸Ú·¥k'ìuëޖf¢–)à–+-­éZÉûz÷¥–+-²Ê.­ÇŸ¢¸ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?–+-Šwèþ·¥k'ìuëÞ


		
---------------------------------
 
 What are the most popular cars?  Find out at Yahoo! Autos

Re: [relayfs-devel] no output

[Tim C. <tim...@ya...>]

Thats correct. Even after you hit ctrl-c to stop the daemon you get nothing. Correct me if I'm wrong but I'm expecting the output to be in either /mnt/relay/klog/cpu0 or the file cpu0 that gets created in the klog source directory.

 tim
 
Tom Zanussi <za...@us...> wrote: Tim Cullen writes:
 > I suspose thats possible. "ps ax" shows them as at least being started, and the very first thing they do is call klog_printk. The thread routine looks like this:
 >  
 >  static void tm_thread( void *arg )
 >  {
 >      klog_printk( "hello from thread %d\n",(int)arg );
 >      while( 1 ) {
 >          set_current_state( TASK_INTERRUPTIBLE );
 >          schedule_timeout( 5 * HZ );
 >      }
 >  }
 >  
 >  So one would expect that the klog_printk call would run, if indeed the thread gets run at all.
 >  

Are you just doing that one klog_printk()?  The output won't be seen
by the daemon until a sub-buffer fills up or the buffer is flushed
when you Ctrl-C to stop the daemon.  You don't see any output even
after you stop the daemon?

I also wonder why even a printk() wouldn't be showing up, strange.

Tom


 >  tim
 > 
 > Tom Zanussi  wrote: Tim Cullen writes:
 >  > Hi Tom
 >  >   
 > > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >  >   
 > > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 >  > 
 >  >   very confusing...
 >  >   
 > 
 > Hmm, could it be possible that the kernel thread doesn't actually run?
 > It sounds like the printk() or klog_printk() calls may not be getting
 > executed for some reason...
 > 
 > Tom
 > 
 >  >   tim
 >  >   
 >  > Tom Zanussi  wrote:  Tim Cullen writes:
 > > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone have ideas whats going on?
 >  >  >  
 >  > 
 >  > Hi,
 >  > 
 >  > Is the klog daemon running when the kernel thread is calling
 >  > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 >  > 
 >  > The reason logging doesn't happen if the daemon isn't running is that
 >  > the klog handler defined in klog-mod.c doesn't actually call
 >  > relay_write() unless 'logging' is true, and 'logging' isn't true until
 >  > the daemon tells it to turn logging on when it starts up, the idea
 >  > being that you normally wouldn't want to log anything unless there's a
 >  > reader to drain the channel.
 >  > 
 >  > Hope that helps,
 >  > 
 >  > Tom
 >  > 
 >  > 
 >  > 
 >  > 
 >  > 
 >  >   
 >  > ---------------------------------
 >  >  
 >  >  What are the most popular cars?  Find out at Yahoo! AutosHi Tom
 >   
 > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >   
 > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 > 
 >   very confusing...
 >   
 >   tim
 >   
 > Tom Zanussi  wrote:  Tim Cullen writes:
 > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread!
 >  >  _create 
 >  >  the output never shows up anywhere. Anyone have ideas whats going on?
 >  >  
 > 
 > Hi,
 > 
 > Is the klog daemon running when the kernel thread is calling
 > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 > 
 > The reason logging doesn't happen if the daemon isn't running is that
 > the klog handler defined in klog-mod.c doesn't actually call
 > relay_write() unless 'logging' is true, and 'logging' isn't true until
 > the daemon tells it to turn logging on when it starts up, the idea
 > being that you normally wouldn't want to log anything unless there's a
 > reader to drain the channel.
 > 
 > Hope that helps,
 > 
 > Tom
 > 
 > 
 > 
 > 
 > 
 >  >   
 > 
 > ---------------------------------
 >  
 >  
 >  > What are the most popular cars?  Find out at Yahoo! Autos
 > 
 > -- 
 > Regards,
 > 
 > Tom Zanussi 
 > IBM Linux Technology Center/RAS
 > 
 > 
 >   
 > ---------------------------------
 > Yahoo! Photos – Showcase holiday pictures in hardcover
 >  Photo Books. You design it and we’ll bind it!I suspose thats possible. "ps ax" shows them as at least being started, and the very first thing they do is call klog_printk. The thread routine looks like this:
 
 static void tm_thread( void *arg )
 {
     klog_printk( "hello from thread %d\n",(int)arg );
     while( 1 ) {
         set_current_state( TASK_INTERRUPTIBLE );
         schedule_timeout( 5 * HZ );
     }
 }
 
 So one would expect that the klog_printk call would run, if indeed the thread gets run at all.
 
 tim

Tom Zanussi <za...@us...> wrote: Tim Cullen writes:
 > Hi Tom
 >   
 > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-a
 >  pps
 > tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >   
 > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 > 
 >   very confusing...
 >   

Hmm, could it be possible that the kernel thread doesn't actually run?
It sounds like the printk() or klog_printk() calls may not be getting
executed for some reason...

Tom

 >   tim
 >   
 > Tom Zanussi  wrote:  Tim Cullen writes:
 > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone hav
 >  e ideas
 >  whats going on?
 >  >  
 > 
 > Hi,
 > 
 > Is the klog daemon running when the kernel thread is calling
 > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 > 
 > The reason logging doesn't happen if the daemon isn't running is that
 > the klog handler defined in klog-mod.c doesn't actually call
 > relay_write() unless 'logging' is true, and 'logging' isn't true until
 > the daemon tells it to turn logging on when it starts up, the idea
 > being that you normally wouldn't want to log anything unless there's a
 > reader to drain the channel.
 > 
 > Hope that helps,
 > 
 > Tom
 > 
 > 
 > 
 > 
 > 
 >   
 > ---------------------------------
 >  
 >  What are the most popular cars?  Find out at Yahoo! AutosHi Tom
  
 Guess I forgot to mention that the klog daemon is 
 >  running.
 > Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
  
 On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.

  very confusing...
  
  tim
  
Tom Zanussi <za...@us...> wrote:  Tim Cullen writes:
 > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread!
 >  _create 
 >  the output never shows up anywhere. Anyone have ideas whats going on?
 >
 >  ; 
 >  

Hi,

Is the klog daemon running when the kernel thread is calling
klog_printk()?  If the klog daemon isn't running, nothing gets logged.

The reason logging doesn't happen if the daemon isn't running is that
the klog handler defined in klog-mod.c doesn't actually call
relay_write() unless 'logging' is true, and 'logging' isn't true until
the daemon tells it to turn logging on when it starts up, the idea
being that you normally wouldn't want to log anything unless there's a
reader to drain the channel.

Hope that helps,

Tom





 >   

---------------------------------
 
 
 > What are the most popular cars?  Find out at Yahoo! Autos

-- 
Regards,

Tom Zanussi 
IBM 
 >  Linux
 >  Technology Center/RAS


 >   

---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 
 > Photo Books. You design it and we’ll bind it!
-- 
Regards,

Tom Zanussi 
IBM Linux Technology Center/RASN¬HY޵隊X¬²š'²ŠÞu¼’¦[§‰ÜŒ¨º
Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£ 塧m…éÞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âž a{› å,àHòÔ4¨m¶Ÿÿ±éZ²ëjY‚w­þÇ¥rg–y$‰õÓ~7Ù¸môãΝjõÛ^¸Ú·¥k'ìuëޖf¢–)à–+-­éZÉûz÷¥–+-²Ê.­ÇŸ¢¸ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?–+-Šwèþ·¥k'ìuëÞ


		
---------------------------------
Yahoo! Photos
 Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.

Re: [relayfs-devel] no output

[Tom Z. <za...@us...>]

VGltIEN1bGxlbiB3cml0ZXM6DQogPiBJIHN1c3Bvc2UgdGhhdHMgcG9zc2libGUuICJwcyBh
eCIgc2hvd3MgdGhlbSBhcyBhdCBsZWFzdCBiZWluZyBzdGFydGVkLCBhbmQgdGhlIHZlcnkg
Zmlyc3QgdGhpbmcgdGhleSBkbyBpcyBjYWxsIGtsb2dfcHJpbnRrLiBUaGUgdGhyZWFkIHJv
dXRpbmUgbG9va3MgbGlrZSB0aGlzOg0KID4gIA0KID4gIHN0YXRpYyB2b2lkIHRtX3RocmVh
ZCggdm9pZCAqYXJnICkNCiA+ICB7DQogPiAgICAgIGtsb2dfcHJpbnRrKCAiaGVsbG8gZnJv
bSB0aHJlYWQgJWRcbiIsKGludClhcmcgKTsNCiA+ICAgICAgd2hpbGUoIDEgKSB7DQogPiAg
ICAgICAgICBzZXRfY3VycmVudF9zdGF0ZSggVEFTS19JTlRFUlJVUFRJQkxFICk7DQogPiAg
ICAgICAgICBzY2hlZHVsZV90aW1lb3V0KCA1ICogSFogKTsNCiA+ICAgICAgfQ0KID4gIH0N
CiA+ICANCiA+ICBTbyBvbmUgd291bGQgZXhwZWN0IHRoYXQgdGhlIGtsb2dfcHJpbnRrIGNh
bGwgd291bGQgcnVuLCBpZiBpbmRlZWQgdGhlIHRocmVhZCBnZXRzIHJ1biBhdCBhbGwuDQog
PiAgDQoNCkFyZSB5b3UganVzdCBkb2luZyB0aGF0IG9uZSBrbG9nX3ByaW50aygpPyAgVGhl
IG91dHB1dCB3b24ndCBiZSBzZWVuDQpieSB0aGUgZGFlbW9uIHVudGlsIGEgc3ViLWJ1ZmZl
ciBmaWxscyB1cCBvciB0aGUgYnVmZmVyIGlzIGZsdXNoZWQNCndoZW4geW91IEN0cmwtQyB0
byBzdG9wIHRoZSBkYWVtb24uICBZb3UgZG9uJ3Qgc2VlIGFueSBvdXRwdXQgZXZlbg0KYWZ0
ZXIgeW91IHN0b3AgdGhlIGRhZW1vbj8NCg0KSSBhbHNvIHdvbmRlciB3aHkgZXZlbiBhIHBy
aW50aygpIHdvdWxkbid0IGJlIHNob3dpbmcgdXAsIHN0cmFuZ2UuDQoNClRvbQ0KDQoNCiA+
ICB0aW0NCiA+IA0KID4gVG9tIFphbnVzc2kgPHphbnVzc2lAdXMuaWJtLmNvbT4gd3JvdGU6
IFRpbSBDdWxsZW4gd3JpdGVzOg0KID4gID4gSGkgVG9tDQogPiAgPiAgIA0KID4gID4gR3Vl
c3MgSSBmb3Jnb3QgdG8gbWVudGlvbiB0aGF0IHRoZSBrbG9nIGRhZW1vbiBpcyBydW5uaW5n
LiBFdmVyeXRoaW5nIGlzIHRoZSBzYW1lIGluIGFzIHRoZSBrbG9nIGV4YW1wbGUgZnJvbSB0
aGUgcmVsYXktYXBwcyB0YXJiYWxsLiBUaGUgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgaW5z
dGVhZCBvZiB1c2luZyB0ZXN0LW1vZC5rbyB0byBnZW5lcmF0ZSBsb2cgZGF0YSwgSSdtIHVz
aW5nIG15IG93biBtb2R1bGUgdGhhdCBjYWxscyBrbG9nX3ByaW50ayBmcm9tIGEga2VybmVs
IHRocmVhZCBzdGFydGVkIGJ5IGt0aHJlYWRfY3JlYXRlLg0KID4gID4gICANCiA+ICA+IE9u
IGEgbWF5YmUtcmVsYXRlZCwgbWF5YmUtbm90LXJlbGF0ZWQgbm90ZSBJJ20gaGF2aW5nIHRo
ZSBzYW1lIHByb2JsZW0gd2l0aCBvdXRwdXQgZnJvbSBwcmludGsgZXZlbiB0aG91Z2ggSSd2
ZSBkb25lIGEgImVjaG8gOCA+IC9wcm9jL3N5cy9rZXJuZWwvcHJpbnRrIiBhcyByb290IGJl
Zm9yZSBoYW5kLg0KID4gID4gDQogPiAgPiAgIHZlcnkgY29uZnVzaW5nLi4uDQogPiAgPiAg
IA0KID4gDQogPiBIbW0sIGNvdWxkIGl0IGJlIHBvc3NpYmxlIHRoYXQgdGhlIGtlcm5lbCB0
aHJlYWQgZG9lc24ndCBhY3R1YWxseSBydW4/DQogPiBJdCBzb3VuZHMgbGlrZSB0aGUgcHJp
bnRrKCkgb3Iga2xvZ19wcmludGsoKSBjYWxscyBtYXkgbm90IGJlIGdldHRpbmcNCiA+IGV4
ZWN1dGVkIGZvciBzb21lIHJlYXNvbi4uLg0KID4gDQogPiBUb20NCiA+IA0KID4gID4gICB0
aW0NCiA+ICA+ICAgDQogPiAgPiBUb20gWmFudXNzaSAgd3JvdGU6ICBUaW0gQ3VsbGVuIHdy
aXRlczoNCiA+ICA+ID4gSSBnb3QgdGhlIGtsb2cgZXhhbXBsZSB3b3JraW5nIHdpdGgga2Vy
bmVsIDIuNi4xNi1yYyB3aXRoIHRlc3QtbW9kLmtvIG91dHB1dHRpbmcgMTIzIHN0cmluZ3Mu
IFRoYXQgYWxsIHdvcmtzIGZpbmUuIEhvd2V2ZXIgd2hlbiBJIHRyeSB1c2luZyBrbG9nX3By
aW50ayBmcm9tIGEga2VybmVsIHRocmVhZCBjcmVhdGVkIGJ5IGt0aHJlYWRfY3JlYXRlIHRo
ZSBvdXRwdXQgbmV2ZXIgc2hvd3MgdXAgYW55d2hlcmUuIEFueW9uZSBoYXZlIGlkZWFzIHdo
YXRzIGdvaW5nIG9uPw0KID4gID4gID4gIA0KID4gID4gDQogPiAgPiBIaSwNCiA+ICA+IA0K
ID4gID4gSXMgdGhlIGtsb2cgZGFlbW9uIHJ1bm5pbmcgd2hlbiB0aGUga2VybmVsIHRocmVh
ZCBpcyBjYWxsaW5nDQogPiAgPiBrbG9nX3ByaW50aygpPyAgSWYgdGhlIGtsb2cgZGFlbW9u
IGlzbid0IHJ1bm5pbmcsIG5vdGhpbmcgZ2V0cyBsb2dnZWQuDQogPiAgPiANCiA+ICA+IFRo
ZSByZWFzb24gbG9nZ2luZyBkb2Vzbid0IGhhcHBlbiBpZiB0aGUgZGFlbW9uIGlzbid0IHJ1
bm5pbmcgaXMgdGhhdA0KID4gID4gdGhlIGtsb2cgaGFuZGxlciBkZWZpbmVkIGluIGtsb2ct
bW9kLmMgZG9lc24ndCBhY3R1YWxseSBjYWxsDQogPiAgPiByZWxheV93cml0ZSgpIHVubGVz
cyAnbG9nZ2luZycgaXMgdHJ1ZSwgYW5kICdsb2dnaW5nJyBpc24ndCB0cnVlIHVudGlsDQog
PiAgPiB0aGUgZGFlbW9uIHRlbGxzIGl0IHRvIHR1cm4gbG9nZ2luZyBvbiB3aGVuIGl0IHN0
YXJ0cyB1cCwgdGhlIGlkZWENCiA+ICA+IGJlaW5nIHRoYXQgeW91IG5vcm1hbGx5IHdvdWxk
bid0IHdhbnQgdG8gbG9nIGFueXRoaW5nIHVubGVzcyB0aGVyZSdzIGENCiA+ICA+IHJlYWRl
ciB0byBkcmFpbiB0aGUgY2hhbm5lbC4NCiA+ICA+IA0KID4gID4gSG9wZSB0aGF0IGhlbHBz
LA0KID4gID4gDQogPiAgPiBUb20NCiA+ICA+IA0KID4gID4gDQogPiAgPiANCiA+ICA+IA0K
ID4gID4gDQogPiAgPiAgIA0KID4gID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQogPiAgPiAgDQogPiAgPiAgV2hhdCBhcmUgdGhlIG1vc3QgcG9wdWxhciBjYXJzPyAg
RmluZCBvdXQgYXQgWWFob28hIEF1dG9zSGkgVG9tDQogPiAgIA0KID4gIEd1ZXNzIEkgZm9y
Z290IHRvIG1lbnRpb24gdGhhdCB0aGUga2xvZyBkYWVtb24gaXMgcnVubmluZy4gRXZlcnl0
aGluZyBpcyB0aGUgc2FtZSBpbiBhcyB0aGUga2xvZyBleGFtcGxlIGZyb20gdGhlIHJlbGF5
LWFwcHMgdGFyYmFsbC4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IGluc3RlYWQgb2Yg
dXNpbmcgdGVzdC1tb2Qua28gdG8gZ2VuZXJhdGUgbG9nIGRhdGEsIEknbSB1c2luZyBteSBv
d24gbW9kdWxlIHRoYXQgY2FsbHMga2xvZ19wcmludGsgZnJvbSBhIGtlcm5lbCB0aHJlYWQg
c3RhcnRlZCBieSBrdGhyZWFkX2NyZWF0ZS4NCiA+ICAgDQogPiAgT24gYSBtYXliZS1yZWxh
dGVkLCBtYXliZS1ub3QtcmVsYXRlZCBub3RlIEknbSBoYXZpbmcgdGhlIHNhbWUgcHJvYmxl
bSB3aXRoIG91dHB1dCBmcm9tIHByaW50ayBldmVuIHRob3VnaCBJJ3ZlIGRvbmUgYSAiZWNo
byA4ID4gL3Byb2Mvc3lzL2tlcm5lbC9wcmludGsiIGFzIHJvb3QgYmVmb3JlIGhhbmQuDQog
PiANCiA+ICAgdmVyeSBjb25mdXNpbmcuLi4NCiA+ICAgDQogPiAgIHRpbQ0KID4gICANCiA+
IFRvbSBaYW51c3NpIDx6YW51c3NpQHVzLmlibS5jb20+IHdyb3RlOiAgVGltIEN1bGxlbiB3
cml0ZXM6DQogPiAgPiBJIGdvdCB0aGUga2xvZyBleGFtcGxlIHdvcmtpbmcgd2l0aCBrZXJu
ZWwgMi42LjE2LXJjIHdpdGggdGVzdC1tb2Qua28gb3V0cHV0dGluZyAxMjMgc3RyaW5ncy4g
VGhhdCBhbGwgd29ya3MgZmluZS4gSG93ZXZlciB3aGVuIEkgdHJ5IHVzaW5nIGtsb2dfcHJp
bnRrIGZyb20gYSBrZXJuZWwgdGhyZWFkIGNyZWF0ZWQgYnkga3RocmVhZCENCiA+ICA+ICBf
Y3JlYXRlIA0KID4gID4gIHRoZSBvdXRwdXQgbmV2ZXIgc2hvd3MgdXAgYW55d2hlcmUuIEFu
eW9uZSBoYXZlIGlkZWFzIHdoYXRzIGdvaW5nIG9uPw0KID4gID4gIA0KID4gDQogPiBIaSwN
CiA+IA0KID4gSXMgdGhlIGtsb2cgZGFlbW9uIHJ1bm5pbmcgd2hlbiB0aGUga2VybmVsIHRo
cmVhZCBpcyBjYWxsaW5nDQogPiBrbG9nX3ByaW50aygpPyAgSWYgdGhlIGtsb2cgZGFlbW9u
IGlzbid0IHJ1bm5pbmcsIG5vdGhpbmcgZ2V0cyBsb2dnZWQuDQogPiANCiA+IFRoZSByZWFz
b24gbG9nZ2luZyBkb2Vzbid0IGhhcHBlbiBpZiB0aGUgZGFlbW9uIGlzbid0IHJ1bm5pbmcg
aXMgdGhhdA0KID4gdGhlIGtsb2cgaGFuZGxlciBkZWZpbmVkIGluIGtsb2ctbW9kLmMgZG9l
c24ndCBhY3R1YWxseSBjYWxsDQogPiByZWxheV93cml0ZSgpIHVubGVzcyAnbG9nZ2luZycg
aXMgdHJ1ZSwgYW5kICdsb2dnaW5nJyBpc24ndCB0cnVlIHVudGlsDQogPiB0aGUgZGFlbW9u
IHRlbGxzIGl0IHRvIHR1cm4gbG9nZ2luZyBvbiB3aGVuIGl0IHN0YXJ0cyB1cCwgdGhlIGlk
ZWENCiA+IGJlaW5nIHRoYXQgeW91IG5vcm1hbGx5IHdvdWxkbid0IHdhbnQgdG8gbG9nIGFu
eXRoaW5nIHVubGVzcyB0aGVyZSdzIGENCiA+IHJlYWRlciB0byBkcmFpbiB0aGUgY2hhbm5l
bC4NCiA+IA0KID4gSG9wZSB0aGF0IGhlbHBzLA0KID4gDQogPiBUb20NCiA+IA0KID4gDQog
PiANCiA+IA0KID4gDQogPiAgPiAgIA0KID4gDQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCiA+ICANCiA+ICANCiA+ICA+IFdoYXQgYXJlIHRoZSBtb3N0IHBvcHVs
YXIgY2Fycz8gIEZpbmQgb3V0IGF0IFlhaG9vISBBdXRvcw0KID4gDQogPiAtLSANCiA+IFJl
Z2FyZHMsDQogPiANCiA+IFRvbSBaYW51c3NpIA0KID4gSUJNIExpbnV4IFRlY2hub2xvZ3kg
Q2VudGVyL1JBUw0KID4gDQogPiANCiA+IAkJDQogPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCiA+IFlhaG9vISBQaG90b3MgliBTaG93Y2FzZSBob2xpZGF5IHBpY3R1
cmVzIGluIGhhcmRjb3Zlcg0KID4gIFBob3RvIEJvb2tzLiBZb3UgZGVzaWduIGl0IGFuZCB3
ZZJsbCBiaW5kIGl0ITxkaXYgaWQ9IlJURUNvbnRlbnQiPkkgc3VzcG9zZSB0aGF0cyBwb3Nz
aWJsZS4gInBzIGF4IiBzaG93cyB0aGVtIGFzIGF0IGxlYXN0IGJlaW5nIHN0YXJ0ZWQsIGFu
ZCB0aGUgdmVyeSBmaXJzdCB0aGluZyB0aGV5IGRvIGlzIGNhbGwga2xvZ19wcmludGsuIFRo
ZSB0aHJlYWQgcm91dGluZSBsb29rcyBsaWtlIHRoaXM6PGJyPiA8YnI+IHN0YXRpYyB2b2lk
IHRtX3RocmVhZCggdm9pZCAqYXJnICk8YnI+IHs8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyBr
bG9nX3ByaW50ayggImhlbGxvIGZyb20gdGhyZWFkICVkXG4iLChpbnQpYXJnICk7PGJyPiAm
bmJzcDsmbmJzcDsmbmJzcDsgd2hpbGUoIDEgKSB7PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsg
Jm5ic3A7Jm5ic3A7ICBzZXRfY3VycmVudF9zdGF0ZSggVEFTS19JTlRFUlJVUFRJQkxFICk7
PGJyPiAmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICBzY2hlZHVsZV90aW1lb3V0
KCA1ICogSFogKTs8YnI+ICZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPiB9PGJyPiA8YnI+IFNv
IG9uZSB3b3VsZCBleHBlY3QgdGhhdCB0aGUga2xvZ19wcmludGsgY2FsbCB3b3VsZCBydW4s
IGlmIGluZGVlZCB0aGUgdGhyZWFkIGdldHMgcnVuIGF0IGFsbC48YnI+IDxicj4gdGltPGJy
Pjxicj48Yj48aT5Ub20gWmFudXNzaSAmbHQ7emFudXNzaUB1cy5pYm0uY29tJmd0OzwvaT48
L2I+IHdyb3RlOjxibG9ja3F1b3RlIGNsYXNzPSJyZXBsYnEiIHN0eWxlPSJib3JkZXItbGVm
dDogMnB4IHNvbGlkIHJnYigxNiwgMTYsIDI1NSk7IG1hcmdpbi1sZWZ0OiA1cHg7IHBhZGRp
bmctbGVmdDogNXB4OyI+IFRpbSBDdWxsZW4gd3JpdGVzOjxicj4gJmd0OyBIaSBUb208YnI+
ICZndDsgICA8YnI+ICZndDsgR3Vlc3MgSSBmb3Jnb3QgdG8gbWVudGlvbiB0aGF0IHRoZSBr
bG9nIGRhZW1vbiBpcyBydW5uaW5nLiBFdmVyeXRoaW5nIGlzIHRoZSBzYW1lIGluIGFzIHRo
ZSBrbG9nIGV4YW1wbGUgZnJvbSB0aGUgcmVsYXktYQ0KID4gIHBwcw0KID4gIHRhcmJhbGwu
IFRoZSBvbmx5IGRpZmZlcmVuY2UgaXMgdGhhdCBpbnN0ZWFkIG9mIHVzaW5nIHRlc3QtbW9k
LmtvIHRvIGdlbmVyYXRlIGxvZyBkYXRhLCBJJ20gdXNpbmcgbXkgb3duIG1vZHVsZSB0aGF0
IGNhbGxzIGtsb2dfcHJpbnRrIGZyb20gYSBrZXJuZWwgdGhyZWFkIHN0YXJ0ZWQgYnkga3Ro
cmVhZF9jcmVhdGUuPGJyPiAmZ3Q7ICAgPGJyPiAmZ3Q7IE9uIGEgbWF5YmUtcmVsYXRlZCwg
bWF5YmUtbm90LXJlbGF0ZWQgbm90ZSBJJ20gaGF2aW5nIHRoZSBzYW1lIHByb2JsZW0gd2l0
aCBvdXRwdXQgZnJvbSBwcmludGsgZXZlbiB0aG91Z2ggSSd2ZSBkb25lIGEgImVjaG8gOCAm
Z3Q7IC9wcm9jL3N5cy9rZXJuZWwvcHJpbnRrIiBhcyByb290IGJlZm9yZSBoYW5kLjxicj4g
Jmd0OyA8YnI+ICZndDsgICB2ZXJ5IGNvbmZ1c2luZy4uLjxicj4gJmd0OyAgIDxicj48YnI+
SG1tLCBjb3VsZCBpdCBiZSBwb3NzaWJsZSB0aGF0IHRoZSBrZXJuZWwgdGhyZWFkIGRvZXNu
J3QgYWN0dWFsbHkgcnVuPzxicj5JdCBzb3VuZHMgbGlrZSB0aGUgcHJpbnRrKCkgb3Iga2xv
Z19wcmludGsoKSBjYWxscyBtYXkgbm90IGJlIGdldHRpbmc8YnI+ZXhlY3V0ZWQgZm9yIHNv
bWUgcmVhc29uLi4uPGJyPjxicj5Ub208YnI+PGJyPiAmZ3Q7ICAgdGltPGJyPiAmZ3Q7ICAg
PGJyPiAmZ3Q7IFRvbSBaYW51c3NpIDx6YW51c3NpIEB1cy5pYm0uY29tPSIiPiB3cm90ZTog
IFRpbSBDdWxsZW4gd3JpdGVzOjxicj4gJmd0OyAmZ3Q7IEkgZ290IHRoZSBrbG9nIGV4YW1w
bGUgd29ya2luZyB3aXRoIGtlcm5lbCAyLjYuMTYtcmMgd2l0aCB0ZXN0LW1vZC5rbyBvdXRw
dXR0aW5nIDEyMyBzdHJpbmdzLiBUaGF0IGFsbCB3b3JrcyBmaW5lLiBIb3dldmVyIHdoZW4g
SSB0cnkgdXNpbmcga2xvZ19wcmludGsgZnJvbSBhIGtlcm5lbCB0aHJlYWQgY3JlYXRlZCBi
eSBrdGhyZWFkX2NyZWF0ZSB0aGUgb3V0cHV0IG5ldmVyIHNob3dzIHVwIGFueXdoZXJlLiBB
bnlvbmUgaGF2DQogPiAgZSBpZGVhcw0KID4gIHdoYXRzIGdvaW5nIG9uPzxicj4gJmd0OyAg
Jmd0OyAgPGJyPiAmZ3Q7IDxicj4gJmd0OyBIaSw8YnI+ICZndDsgPGJyPiAmZ3Q7IElzIHRo
ZSBrbG9nIGRhZW1vbiBydW5uaW5nIHdoZW4gdGhlIGtlcm5lbCB0aHJlYWQgaXMgY2FsbGlu
Zzxicj4gJmd0OyBrbG9nX3ByaW50aygpPyAgSWYgdGhlIGtsb2cgZGFlbW9uIGlzbid0IHJ1
bm5pbmcsIG5vdGhpbmcgZ2V0cyBsb2dnZWQuPGJyPiAmZ3Q7IDxicj4gJmd0OyBUaGUgcmVh
c29uIGxvZ2dpbmcgZG9lc24ndCBoYXBwZW4gaWYgdGhlIGRhZW1vbiBpc24ndCBydW5uaW5n
IGlzIHRoYXQ8YnI+ICZndDsgdGhlIGtsb2cgaGFuZGxlciBkZWZpbmVkIGluIGtsb2ctbW9k
LmMgZG9lc24ndCBhY3R1YWxseSBjYWxsPGJyPiAmZ3Q7IHJlbGF5X3dyaXRlKCkgdW5sZXNz
ICdsb2dnaW5nJyBpcyB0cnVlLCBhbmQgJ2xvZ2dpbmcnIGlzbid0IHRydWUgdW50aWw8YnI+
ICZndDsgdGhlIGRhZW1vbiB0ZWxscyBpdCB0byB0dXJuIGxvZ2dpbmcgb24gd2hlbiBpdCBz
dGFydHMgdXAsIHRoZSBpZGVhPGJyPiAmZ3Q7IGJlaW5nIHRoYXQgeW91IG5vcm1hbGx5IHdv
dWxkbid0IHdhbnQgdG8gbG9nIGFueXRoaW5nIHVubGVzcyB0aGVyZSdzIGE8YnI+ICZndDsg
cmVhZGVyIHRvIGRyYWluIHRoZSBjaGFubmVsLjxicj4gJmd0OyA8YnI+ICZndDsgSG9wZSB0
aGF0IGhlbHBzLDxicj4gJmd0OyA8YnI+ICZndDsgVG9tPGJyPiAmZ3Q7IDxicj4gJmd0OyA8
YnI+ICZndDsgPGJyPiAmZ3Q7IDxicj4gJmd0OyA8YnI+ICZndDsgICA8YnI+ICZndDsgLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiAmZ3Q7ICA8YnI+ICZndDsgIFdo
YXQgYXJlIHRoZSBtb3N0IHBvcHVsYXIgY2Fycz8gIEZpbmQgb3V0IGF0IFlhaG9vISBBdXRv
czwvemFudXNzaT48ZGl2IGlkPSJSVEVDb250ZW50Ij5IaSBUb208YnI+ICA8YnI+IEd1ZXNz
IEkgZm9yZ290IHRvIG1lbnRpb24gdGhhdCB0aGUga2xvZyBkYWVtb24gaXMgDQogPiAgcnVu
bmluZy4NCiA+ICBFdmVyeXRoaW5nIGlzIHRoZSBzYW1lIGluIGFzIHRoZSBrbG9nIGV4YW1w
bGUgZnJvbSB0aGUgcmVsYXktYXBwcyB0YXJiYWxsLiBUaGUgb25seSBkaWZmZXJlbmNlIGlz
IHRoYXQgaW5zdGVhZCBvZiB1c2luZyB0ZXN0LW1vZC5rbyB0byBnZW5lcmF0ZSBsb2cgZGF0
YSwgSSdtIHVzaW5nIG15IG93biBtb2R1bGUgdGhhdCBjYWxscyBrbG9nX3ByaW50ayBmcm9t
IGEga2VybmVsIHRocmVhZCBzdGFydGVkIGJ5IGt0aHJlYWRfY3JlYXRlLjxicj4gIDxicj4g
T24gYSBtYXliZS1yZWxhdGVkLCBtYXliZS1ub3QtcmVsYXRlZCBub3RlIEknbSBoYXZpbmcg
dGhlIHNhbWUgcHJvYmxlbSB3aXRoIG91dHB1dCBmcm9tIHByaW50ayBldmVuIHRob3VnaCBJ
J3ZlIGRvbmUgYSAiZWNobyA4ICZndDsgL3Byb2Mvc3lzL2tlcm5lbC9wcmludGsiIGFzIHJv
b3QgYmVmb3JlIGhhbmQuPGJyPjxicj4gIHZlcnkgY29uZnVzaW5nLi4uPGJyPiAgPGJyPiAg
dGltPGJyPiAgPGJyPjxiPjxpPlRvbSBaYW51c3NpICZsdDt6YW51c3NpQHVzLmlibS5jb20m
Z3Q7PC9pPjwvYj4gd3JvdGU6PGJsb2NrcXVvdGUgY2xhc3M9InJlcGxicSIgc3R5bGU9ImJv
cmRlci1sZWZ0OiAycHggc29saWQgcmdiKDE2LCAxNiwgMjU1KTsgbWFyZ2luLWxlZnQ6IDVw
eDsgcGFkZGluZy1sZWZ0OiA1cHg7Ij4gIFRpbSBDdWxsZW4gd3JpdGVzOjxicj4gJmd0OyBJ
IGdvdCB0aGUga2xvZyBleGFtcGxlIHdvcmtpbmcgd2l0aCBrZXJuZWwgMi42LjE2LXJjIHdp
dGggdGVzdC1tb2Qua28gb3V0cHV0dGluZyAxMjMgc3RyaW5ncy4gVGhhdCBhbGwgd29ya3Mg
ZmluZS4gSG93ZXZlciB3aGVuIEkgdHJ5IHVzaW5nIGtsb2dfcHJpbnRrIGZyb20gYSBrZXJu
ZWwgdGhyZWFkIGNyZWF0ZWQgYnkga3RocmVhZCE8YnI+ICZndDsgIF9jcmVhdGUgPGJyPiAm
Z3Q7ICB0aGUgb3V0cHV0IG5ldmVyIHNob3dzIHVwIGFueXdoZXJlLiBBbnlvbmUgaGF2ZSBp
ZGVhcyB3aGF0cyBnb2luZyBvbj88YnI+ICZndA0KID4gIDsgDQogPiAgPGJyPjxicj5IaSw8
YnI+PGJyPklzIHRoZSBrbG9nIGRhZW1vbiBydW5uaW5nIHdoZW4gdGhlIGtlcm5lbCB0aHJl
YWQgaXMgY2FsbGluZzxicj5rbG9nX3ByaW50aygpPyAgSWYgdGhlIGtsb2cgZGFlbW9uIGlz
bid0IHJ1bm5pbmcsIG5vdGhpbmcgZ2V0cyBsb2dnZWQuPGJyPjxicj5UaGUgcmVhc29uIGxv
Z2dpbmcgZG9lc24ndCBoYXBwZW4gaWYgdGhlIGRhZW1vbiBpc24ndCBydW5uaW5nIGlzIHRo
YXQ8YnI+dGhlIGtsb2cgaGFuZGxlciBkZWZpbmVkIGluIGtsb2ctbW9kLmMgZG9lc24ndCBh
Y3R1YWxseSBjYWxsPGJyPnJlbGF5X3dyaXRlKCkgdW5sZXNzICdsb2dnaW5nJyBpcyB0cnVl
LCBhbmQgJ2xvZ2dpbmcnIGlzbid0IHRydWUgdW50aWw8YnI+dGhlIGRhZW1vbiB0ZWxscyBp
dCB0byB0dXJuIGxvZ2dpbmcgb24gd2hlbiBpdCBzdGFydHMgdXAsIHRoZSBpZGVhPGJyPmJl
aW5nIHRoYXQgeW91IG5vcm1hbGx5IHdvdWxkbid0IHdhbnQgdG8gbG9nIGFueXRoaW5nIHVu
bGVzcyB0aGVyZSdzIGE8YnI+cmVhZGVyIHRvIGRyYWluIHRoZSBjaGFubmVsLjxicj48YnI+
SG9wZSB0aGF0IGhlbHBzLDxicj48YnI+VG9tPGJyPjxicj48YnI+PC9ibG9ja3F1b3RlPjxi
cj48L2Rpdj48ZGl2Pjxicj4gJmd0OyAgIDwvZGl2PjxociBzaXplPSIxIj4gPGJyPiA8YnI+
ICZndDsgV2hhdCBhcmUgdGhlIG1vc3QgcG9wdWxhciBjYXJzPyAgRmluZCBvdXQgYXQgPGEg
aHJlZj0iaHR0cDovL3VzLnJkLnlhaG9vLmNvbS9ldnQ9MzgzODIvX3lsYz1YM29ETVRFek5X
RnZhMlkyQkY5VEF6azNNVEEzTURjMkJITmxZd050WVdsc2RHRm5jd1J6YkdzRE1tRjFkRzl6
LypodHRwOi8vYXV0b3MueWFob28uY29tL25ld2NhcnMvcG9wdWxhci90aGlzd2Vlay5odG1s
JTIwJTNDYnIlM0UlMjAlM0UlMjAiPllhaG9vISBBdXRvczwvYT48YnI+PGJyPi0tIDxicj5S
ZWdhcmRzLDxicj48YnI+VG9tIFphbnVzc2kgPHphbnVzc2kgQHVzLmlibS5jb209IiI+PGJy
PklCTSANCiA+ICBMaW51eA0KID4gIFRlY2hub2xvZ3kgQ2VudGVyL1JBUzwvemFudXNzaT48
L2Jsb2NrcXVvdGU+PGJyPjwvZGl2PjxwPg0KID4gCQk8aHIgc2l6ZT0xPllhaG9vISBQaG90
b3MgliBTaG93Y2FzZSBob2xpZGF5IHBpY3R1cmVzIGluIGhhcmRjb3Zlcjxicj4gDQogPiA8
YSBocmVmPSJodHRwOi8vdXMucmQueWFob28uY29tL21haWxfdXMvdGFnbGluZXMvcGhvdG9i
b29rcy8qaHR0cDovL3BhLnlhaG9vLmNvbS8qaHR0cDovL3VzLnJkLnlhaG9vLmNvbS9tYWls
X3VzL3RhZ2xpbmVzL3Bob3Rvcy9ldnQ9MzgwODgvKmh0dHA6Ly9wZy5waG90b3MueWFob28u
Y29tL3BoLy9wYWdlPy5maWxlPXBob3RvYm9va19zcGxhc2guaHRtbCI+UGhvdG8gQm9va3M8
L2E+LiBZb3UgZGVzaWduIGl0IGFuZCB3ZZJsbCBiaW5kIGl0IQ0KLS0gDQpSZWdhcmRzLA0K
DQpUb20gWmFudXNzaSA8emFudXNzaUB1cy5pYm0uY29tPg0KSUJNIExpbnV4IFRlY2hub2xv
Z3kgQ2VudGVyL1JBUw==

Re: [relayfs-devel] no output

[Tim C. <tim...@ya...>]

I suspose thats possible. "ps ax" shows them as at least being started, and the very first thing they do is call klog_printk. The thread routine looks like this:
 
 static void tm_thread( void *arg )
 {
     klog_printk( "hello from thread %d\n",(int)arg );
     while( 1 ) {
         set_current_state( TASK_INTERRUPTIBLE );
         schedule_timeout( 5 * HZ );
     }
 }
 
 So one would expect that the klog_printk call would run, if indeed the thread gets run at all.
 
 tim

Tom Zanussi <za...@us...> wrote: Tim Cullen writes:
 > Hi Tom
 >   
 > Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
 >   
 > On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.
 > 
 >   very confusing...
 >   

Hmm, could it be possible that the kernel thread doesn't actually run?
It sounds like the printk() or klog_printk() calls may not be getting
executed for some reason...

Tom

 >   tim
 >   
 > Tom Zanussi  wrote:  Tim Cullen writes:
 > > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone have ideas whats going on?
 >  >  
 > 
 > Hi,
 > 
 > Is the klog daemon running when the kernel thread is calling
 > klog_printk()?  If the klog daemon isn't running, nothing gets logged.
 > 
 > The reason logging doesn't happen if the daemon isn't running is that
 > the klog handler defined in klog-mod.c doesn't actually call
 > relay_write() unless 'logging' is true, and 'logging' isn't true until
 > the daemon tells it to turn logging on when it starts up, the idea
 > being that you normally wouldn't want to log anything unless there's a
 > reader to drain the channel.
 > 
 > Hope that helps,
 > 
 > Tom
 > 
 > 
 > 
 > 
 > 
 >   
 > ---------------------------------
 >  
 >  What are the most popular cars?  Find out at Yahoo! AutosHi Tom
  
 Guess I forgot to mention that the klog daemon is running. Everything is the same in as the klog example from the relay-apps tarball. The only difference is that instead of using test-mod.ko to generate log data, I'm using my own module that calls klog_printk from a kernel thread started by kthread_create.
  
 On a maybe-related, maybe-not-related note I'm having the same problem with output from printk even though I've done a "echo 8 > /proc/sys/kernel/printk" as root before hand.

  very confusing...
  
  tim
  
Tom Zanussi <za...@us...> wrote:  Tim Cullen writes:
 > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread!
 >  _create 
 >  the output never shows up anywhere. Anyone have ideas whats going on?
 >  

Hi,

Is the klog daemon running when the kernel thread is calling
klog_printk()?  If the klog daemon isn't running, nothing gets logged.

The reason logging doesn't happen if the daemon isn't running is that
the klog handler defined in klog-mod.c doesn't actually call
relay_write() unless 'logging' is true, and 'logging' isn't true until
the daemon tells it to turn logging on when it starts up, the idea
being that you normally wouldn't want to log anything unless there's a
reader to drain the channel.

Hope that helps,

Tom





 >   

---------------------------------
 
 
 > What are the most popular cars?  Find out at Yahoo! Autos

-- 
Regards,

Tom Zanussi 
IBM Linux Technology Center/RAS


		
---------------------------------
Yahoo! Photos – Showcase holiday pictures in hardcover
 Photo Books. You design it and we’ll bind it!

Re: [relayfs-devel] no output

[Tom Z. <za...@us...>]

VGltIEN1bGxlbiB3cml0ZXM6DQogPiBIaSBUb20NCiA+ICAgDQogPiAgIEd1ZXNzIEkgZm9y
Z290IHRvIG1lbnRpb24gdGhhdCB0aGUga2xvZyBkYWVtb24gaXMgcnVubmluZy4gRXZlcnl0
aGluZyAgaXMgdGhlIHNhbWUgaW4gYXMgdGhlIGtsb2cgZXhhbXBsZSBmcm9tIHRoZSByZWxh
eS1hcHBzIHRhcmJhbGwuIFRoZSAgb25seSBkaWZmZXJlbmNlIGlzIHRoYXQgaW5zdGVhZCBv
ZiB1c2luZyB0ZXN0LW1vZC5rbyB0byBnZW5lcmF0ZSBsb2cgIGRhdGEsIEknbSB1c2luZyBt
eSBvd24gbW9kdWxlIHRoYXQgY2FsbHMga2xvZ19wcmludGsgZnJvbSBhIGtlcm5lbCAgdGhy
ZWFkIHN0YXJ0ZWQgYnkga3RocmVhZF9jcmVhdGUuDQogPiAgIA0KID4gICBPbiBhIG1heWJl
LXJlbGF0ZWQsIG1heWJlLW5vdC1yZWxhdGVkIG5vdGUgSSdtIGhhdmluZyB0aGUgc2FtZSBw
cm9ibGVtICB3aXRoIG91dHB1dCBmcm9tIHByaW50ayBldmVuIHRob3VnaCBJJ3ZlIGRvbmUg
YSAiZWNobyA4ID4gIC9wcm9jL3N5cy9rZXJuZWwvcHJpbnRrIiBhcyByb290IGJlZm9yZSBo
YW5kLg0KID4gDQogPiAgIHZlcnkgY29uZnVzaW5nLi4uDQogPiAgIA0KDQpIbW0sIGNvdWxk
IGl0IGJlIHBvc3NpYmxlIHRoYXQgdGhlIGtlcm5lbCB0aHJlYWQgZG9lc24ndCBhY3R1YWxs
eSBydW4/DQpJdCBzb3VuZHMgbGlrZSB0aGUgcHJpbnRrKCkgb3Iga2xvZ19wcmludGsoKSBj
YWxscyBtYXkgbm90IGJlIGdldHRpbmcNCmV4ZWN1dGVkIGZvciBzb21lIHJlYXNvbi4uLg0K
DQpUb20NCg0KID4gICB0aW0NCiA+ICAgDQogPiBUb20gWmFudXNzaSA8emFudXNzaUB1cy5p
Ym0uY29tPiB3cm90ZTogIFRpbSBDdWxsZW4gd3JpdGVzOg0KID4gICA+IEkgZ290IHRoZSBr
bG9nIGV4YW1wbGUgd29ya2luZyB3aXRoIGtlcm5lbCAyLjYuMTYtcmMgd2l0aCAgdGVzdC1t
b2Qua28gb3V0cHV0dGluZyAxMjMgc3RyaW5ncy4gVGhhdCBhbGwgd29ya3MgZmluZS4gSG93
ZXZlciB3aGVuIEkgIHRyeSB1c2luZyBrbG9nX3ByaW50ayBmcm9tIGEga2VybmVsIHRocmVh
ZCBjcmVhdGVkIGJ5IGt0aHJlYWRfY3JlYXRlICB0aGUgb3V0cHV0IG5ldmVyIHNob3dzIHVw
IGFueXdoZXJlLiBBbnlvbmUgaGF2ZSBpZGVhcyB3aGF0cyBnb2luZyBvbj8NCiA+ICA+ICAN
CiA+IA0KID4gSGksDQogPiANCiA+IElzIHRoZSBrbG9nIGRhZW1vbiBydW5uaW5nIHdoZW4g
dGhlIGtlcm5lbCB0aHJlYWQgaXMgY2FsbGluZw0KID4ga2xvZ19wcmludGsoKT8gIElmIHRo
ZSBrbG9nIGRhZW1vbiBpc24ndCBydW5uaW5nLCBub3RoaW5nIGdldHMgbG9nZ2VkLg0KID4g
DQogPiBUaGUgcmVhc29uIGxvZ2dpbmcgZG9lc24ndCBoYXBwZW4gaWYgdGhlIGRhZW1vbiBp
c24ndCBydW5uaW5nIGlzIHRoYXQNCiA+IHRoZSBrbG9nIGhhbmRsZXIgZGVmaW5lZCBpbiBr
bG9nLW1vZC5jIGRvZXNuJ3QgYWN0dWFsbHkgY2FsbA0KID4gcmVsYXlfd3JpdGUoKSB1bmxl
c3MgJ2xvZ2dpbmcnIGlzIHRydWUsIGFuZCAnbG9nZ2luZycgaXNuJ3QgdHJ1ZSB1bnRpbA0K
ID4gdGhlIGRhZW1vbiB0ZWxscyBpdCB0byB0dXJuIGxvZ2dpbmcgb24gd2hlbiBpdCBzdGFy
dHMgdXAsIHRoZSBpZGVhDQogPiBiZWluZyB0aGF0IHlvdSBub3JtYWxseSB3b3VsZG4ndCB3
YW50IHRvIGxvZyBhbnl0aGluZyB1bmxlc3MgdGhlcmUncyBhDQogPiByZWFkZXIgdG8gZHJh
aW4gdGhlIGNoYW5uZWwuDQogPiANCiA+IEhvcGUgdGhhdCBoZWxwcywNCiA+IA0KID4gVG9t
DQogPiANCiA+IA0KID4gDQogPiANCiA+IA0KID4gCQkNCiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KID4gIA0KID4gIFdoYXQgYXJlIHRoZSBtb3N0IHBvcHVsYXIg
Y2Fycz8gIEZpbmQgb3V0IGF0IFlhaG9vISBBdXRvczxkaXYgaWQ9IlJURUNvbnRlbnQiPkhp
IFRvbTxicj4gIDxicj4gIEd1ZXNzIEkgZm9yZ290IHRvIG1lbnRpb24gdGhhdCB0aGUga2xv
ZyBkYWVtb24gaXMgcnVubmluZy4gRXZlcnl0aGluZyAgaXMgdGhlIHNhbWUgaW4gYXMgdGhl
IGtsb2cgZXhhbXBsZSBmcm9tIHRoZSByZWxheS1hcHBzIHRhcmJhbGwuIFRoZSAgb25seSBk
aWZmZXJlbmNlIGlzIHRoYXQgaW5zdGVhZCBvZiB1c2luZyB0ZXN0LW1vZC5rbyB0byBnZW5l
cmF0ZSBsb2cgIGRhdGEsIEknbSB1c2luZyBteSBvd24gbW9kdWxlIHRoYXQgY2FsbHMga2xv
Z19wcmludGsgZnJvbSBhIGtlcm5lbCAgdGhyZWFkIHN0YXJ0ZWQgYnkga3RocmVhZF9jcmVh
dGUuPGJyPiAgPGJyPiAgT24gYSBtYXliZS1yZWxhdGVkLCBtYXliZS1ub3QtcmVsYXRlZCBu
b3RlIEknbSBoYXZpbmcgdGhlIHNhbWUgcHJvYmxlbSAgd2l0aCBvdXRwdXQgZnJvbSBwcmlu
dGsgZXZlbiB0aG91Z2ggSSd2ZSBkb25lIGEgImVjaG8gOCAmZ3Q7ICAvcHJvYy9zeXMva2Vy
bmVsL3ByaW50ayIgYXMgcm9vdCBiZWZvcmUgaGFuZC48YnI+PGJyPiAgdmVyeSBjb25mdXNp
bmcuLi48YnI+ICA8YnI+ICB0aW08YnI+ICA8YnI+PGI+PGk+VG9tIFphbnVzc2kgJmx0O3ph
bnVzc2lAdXMuaWJtLmNvbSZndDs8L2k+PC9iPiB3cm90ZTo8YmxvY2txdW90ZSBjbGFzcz0i
cmVwbGJxIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCByZ2IoMTYsIDE2LCAyNTUp
OyBtYXJnaW4tbGVmdDogNXB4OyBwYWRkaW5nLWxlZnQ6IDVweDsiPiAgVGltIEN1bGxlbiB3
cml0ZXM6PGJyPiAgJmd0OyBJIGdvdCB0aGUga2xvZyBleGFtcGxlIHdvcmtpbmcgd2l0aCBr
ZXJuZWwgMi42LjE2LXJjIHdpdGggIHRlc3QtbW9kLmtvIG91dHB1dHRpbmcgMTIzIHN0cmlu
Z3MuIFRoYXQgYWxsIHdvcmtzIGZpbmUuIEhvd2V2ZXIgd2hlbiBJICB0cnkgdXNpbmcga2xv
Z19wcmludGsgZnJvbSBhIGtlcm5lbCB0aHJlYWQgY3JlYXRlZCBieSBrdGhyZWFkIQ0KID4g
IF9jcmVhdGUgDQogPiAgdGhlIG91dHB1dCBuZXZlciBzaG93cyB1cCBhbnl3aGVyZS4gQW55
b25lIGhhdmUgaWRlYXMgd2hhdHMgZ29pbmcgb24/PGJyPiAmZ3Q7ICA8YnI+PGJyPkhpLDxi
cj48YnI+SXMgdGhlIGtsb2cgZGFlbW9uIHJ1bm5pbmcgd2hlbiB0aGUga2VybmVsIHRocmVh
ZCBpcyBjYWxsaW5nPGJyPmtsb2dfcHJpbnRrKCk/ICBJZiB0aGUga2xvZyBkYWVtb24gaXNu
J3QgcnVubmluZywgbm90aGluZyBnZXRzIGxvZ2dlZC48YnI+PGJyPlRoZSByZWFzb24gbG9n
Z2luZyBkb2Vzbid0IGhhcHBlbiBpZiB0aGUgZGFlbW9uIGlzbid0IHJ1bm5pbmcgaXMgdGhh
dDxicj50aGUga2xvZyBoYW5kbGVyIGRlZmluZWQgaW4ga2xvZy1tb2QuYyBkb2Vzbid0IGFj
dHVhbGx5IGNhbGw8YnI+cmVsYXlfd3JpdGUoKSB1bmxlc3MgJ2xvZ2dpbmcnIGlzIHRydWUs
IGFuZCAnbG9nZ2luZycgaXNuJ3QgdHJ1ZSB1bnRpbDxicj50aGUgZGFlbW9uIHRlbGxzIGl0
IHRvIHR1cm4gbG9nZ2luZyBvbiB3aGVuIGl0IHN0YXJ0cyB1cCwgdGhlIGlkZWE8YnI+YmVp
bmcgdGhhdCB5b3Ugbm9ybWFsbHkgd291bGRuJ3Qgd2FudCB0byBsb2cgYW55dGhpbmcgdW5s
ZXNzIHRoZXJlJ3MgYTxicj5yZWFkZXIgdG8gZHJhaW4gdGhlIGNoYW5uZWwuPGJyPjxicj5I
b3BlIHRoYXQgaGVscHMsPGJyPjxicj5Ub208YnI+PGJyPjxicj48L2Jsb2NrcXVvdGU+PGJy
PjwvZGl2PjxwPg0KID4gCQk8aHIgc2l6ZT0xPiA8QlI+IA0KID4gV2hhdCBhcmUgdGhlIG1v
c3QgcG9wdWxhciBjYXJzPyAgRmluZCBvdXQgYXQgPGEgaHJlZj0iaHR0cDovL3VzLnJkLnlh
aG9vLmNvbS9ldnQ9MzgzODIvX3lsYz1YM29ETVRFek5XRnZhMlkyQkY5VEF6azNNVEEzTURj
MkJITmxZd050WVdsc2RHRm5jd1J6YkdzRE1tRjFkRzl6LypodHRwOi8vYXV0b3MueWFob28u
Y29tL25ld2NhcnMvcG9wdWxhci90aGlzd2Vlay5odG1sIA0KID4gIj5ZYWhvbyEgQXV0b3M8
L2E+DQoNCi0tIA0KUmVnYXJkcywNCg0KVG9tIFphbnVzc2kgPHphbnVzc2lAdXMuaWJtLmNv
bT4NCklCTSBMaW51eCBUZWNobm9sb2d5IENlbnRlci9SQVM=

Re: [relayfs-devel] no output

[Tim C. <tim...@ya...>]

Hi Tom
  
  Guess I forgot to mention that the klog daemon is running. Everything  is the same in as the klog example from the relay-apps tarball. The  only difference is that instead of using test-mod.ko to generate log  data, I'm using my own module that calls klog_printk from a kernel  thread started by kthread_create.
  
  On a maybe-related, maybe-not-related note I'm having the same problem  with output from printk even though I've done a "echo 8 >  /proc/sys/kernel/printk" as root before hand.

  very confusing...
  
  tim
  
Tom Zanussi <za...@us...> wrote:  Tim Cullen writes:
  > I got the klog example working with kernel 2.6.16-rc with  test-mod.ko outputting 123 strings. That all works fine. However when I  try using klog_printk from a kernel thread created by kthread_create  the output never shows up anywhere. Anyone have ideas whats going on?
 >  

Hi,

Is the klog daemon running when the kernel thread is calling
klog_printk()?  If the klog daemon isn't running, nothing gets logged.

The reason logging doesn't happen if the daemon isn't running is that
the klog handler defined in klog-mod.c doesn't actually call
relay_write() unless 'logging' is true, and 'logging' isn't true until
the daemon tells it to turn logging on when it starts up, the idea
being that you normally wouldn't want to log anything unless there's a
reader to drain the channel.

Hope that helps,

Tom





		
---------------------------------
 
 What are the most popular cars?  Find out at Yahoo! Autos

Re: [relayfs-devel] no output

[Tom Z. <za...@us...>]

Tim Cullen writes:
 > I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone have ideas whats going on?
 >  

Hi,

Is the klog daemon running when the kernel thread is calling
klog_printk()?  If the klog daemon isn't running, nothing gets logged.

The reason logging doesn't happen if the daemon isn't running is that
the klog handler defined in klog-mod.c doesn't actually call
relay_write() unless 'logging' is true, and 'logging' isn't true until
the daemon tells it to turn logging on when it starts up, the idea
being that you normally wouldn't want to log anything unless there's a
reader to drain the channel.

Hope that helps,

Tom

[relayfs-devel] no output

[Tim C. <tim...@ya...>]

I got the klog example working with kernel 2.6.16-rc with test-mod.ko outputting 123 strings. That all works fine. However when I try using klog_printk from a kernel thread created by kthread_create the output never shows up anywhere. Anyone have ideas whats going on?
 
 tim
 
 

			
---------------------------------
Yahoo! Photos
 Got holiday prints? See all the ways to get quality prints in your hands ASAP.

Re: [relayfs-devel] Problems trying to insert klog-mod.ko module

[Tom Z. <za...@us...>]

Bruno de Oliveira Abinader writes:
 > Hi everybody, I'm using relayfs to extract some informations with klog() 
 > functions on my kernel (version 2.6.15), so I enabled both relayfs and 
 > klog (this last using klog.patch). Then I used klog example from 
 > relay-apps version 0.8 (that still uses relay-app and librelay.c files) 
 > and it seems to work (cpu0..cpuX files are created on my user-space). 
 > Now I want to try klog from relay-apps version 0.91 (available at 
 > sourceforge.net). This klog uses the new API, that doesn't need 
 > relay-app and etc. Ok, I tried to compile it and I got the following 
 > message on my console:
 > 
 > *** Warning: "relayfs_create_file" [/home/bruno/klog/klog-mod.ko] undefined!
 > *** Warning: "relayfs_remove_file" [/home/bruno/klog/klog-mod.ko] undefined!
 > 
 > But it still compiled. Then I tried to do a "sudo insmod klog-mod.ko" 
 > and I got this:
 > 
 > insmod: error inserting 'klog-mod.ko': -1 Invalid module format
 > 
 > I studied the inode.c file from relayfs and, apparently, from version 
 > 2.6.15 it doesn't mention the "relayfs_create_file" and 
 > "relayfs_remove_file" functions, so I think I'm using old versions of 
 > relayfs driver. Am I correct or there is another problem that i'm not 
 > finding? Thanks in advance for your help.

Hi,

The 0.91 version of relay-apps will work with the latest git kernel or
the 2.6.15 -mm kernel 2.6.15-mm2 - the additional features it depends
on sat in -mm for awhile and just got moved over to the mainline
kernel (and removed from 2.6.15-mm3).

Hope that helps,

Tom

[relayfs-devel] Problems trying to insert klog-mod.ko module

[Bruno de O. A. <bru...@in...>]

Hi everybody, I'm using relayfs to extract some informations with klog() 
functions on my kernel (version 2.6.15), so I enabled both relayfs and 
klog (this last using klog.patch). Then I used klog example from 
relay-apps version 0.8 (that still uses relay-app and librelay.c files) 
and it seems to work (cpu0..cpuX files are created on my user-space). 
Now I want to try klog from relay-apps version 0.91 (available at 
sourceforge.net). This klog uses the new API, that doesn't need 
relay-app and etc. Ok, I tried to compile it and I got the following 
message on my console:

*** Warning: "relayfs_create_file" [/home/bruno/klog/klog-mod.ko] undefined!
*** Warning: "relayfs_remove_file" [/home/bruno/klog/klog-mod.ko] undefined!

But it still compiled. Then I tried to do a "sudo insmod klog-mod.ko" 
and I got this:

insmod: error inserting 'klog-mod.ko': -1 Invalid module format

I studied the inode.c file from relayfs and, apparently, from version 
2.6.15 it doesn't mention the "relayfs_create_file" and 
"relayfs_remove_file" functions, so I think I'm using old versions of 
relayfs driver. Am I correct or there is another problem that i'm not 
finding? Thanks in advance for your help.

[]s

-- 

Bruno de Oliveira Abinader
INdT - 10Le

Re: [relayfs-devel] [PATCH] librelay.c: fix memory leak in send_request()

[Michael D. <md...@go...>]

Tom Zanussi wrote:

>I can continue maintaining a netlink/relay-app.h/librelay version if
>that's of interest, though...
>
>  
>
No need.

We are using the current version right now, but what you
are proposing sounds much nicer and we will probably
switch to it as soon as it is available.

md

Re: [relayfs-devel] [PATCH] librelay.c: fix memory leak in send_request()

[Tom Z. <za...@us...>]

Michael Davidson writes:
 > 
 > Fix memory leak in send_request() and remove an unnecessary
 > type cast of the return value from malloc.

Hi,

Thanks for the patch.

I'll be updating the relay-apps code soon, but the new version doesn't
use netlink any longer; in fact relay-app.h and librelay.c are also
gone - I've converted all the examples to be standalone and to use
'control files' in relayfs, which I'll also be submitting a relayfs
patch for.

I can continue maintaining a netlink/relay-app.h/librelay version if
that's of interest, though...

Tom

[relayfs-devel] [PATCH] librelay.c: fix memory leak in send_request()

[Michael D. <md...@go...>]

Fix memory leak in send_request() and remove an unnecessary
type cast of the return value from malloc.

Signed-off-by: Michael Davidson <md...@go...>

--- relay-apps-0.8/librelay.c	2005-08-05 10:03:30.000000000 -0700
+++ relay-apps/librelay.c	2005-10-05 11:01:18.000000000 -0700
@@ -106,7 +106,7 @@
 	struct nlmsghdr *req;
 	int err;
 
-	req = (struct nlmsghdr *)malloc(NLMSG_SPACE(len));
+	req = malloc(NLMSG_SPACE(len));
 	memset(req, 0, NLMSG_SPACE(len));
 	req->nlmsg_len = NLMSG_LENGTH(len);
 	req->nlmsg_type = type;
@@ -117,6 +117,9 @@
 	err = send(control_channel, req, req->nlmsg_len, 0);
 	if (err < 0)
 		fprintf(stderr, "netlink send error\n");
+
+	free(req);
+
 	return err;
 }
 

[relayfs-devel] Re: [PATCH] Re: relayfs documentation sucks?

[bert h. <ber...@ne...>]

On Mon, Jul 25, 2005 at 07:47:45PM -0400, Karim Yaghmour wrote:

> Now if only I could remember what I talked about after I left the Black
> Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
> button and said "'M' for more beer" ...

I bet in involved 'M' for more markers, Karim :-)

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

[relayfs-devel] Re: [PATCH] Re: relayfs documentation sucks?

[Karim Y. <ka...@op...>]

Christoph Hellwig wrote:
> That beein said I wish LTT folks would make a little more progress so
> we could actually include it.

We're working on it. On the topic of revamping LTT, 3 different people
came up with 3 different implementations.

Following your feedback on the patch I sent a few weeks back, I headed
out asking myself "what is the bare-minimum tracing functionality that
will actually fly while still being flexible enough to add to it?" I
spent some time at the OLS comparing notes with others interested in this
area, and I think we've got something that should fit the bill. We should
be able to post something sooner rather than later.

Now if only I could remember what I talked about after I left the Black
Thorn at 2h45am and the guy in the elevator at Les Suites pressed on a
button and said "'M' for more beer" ...

Thanks,

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || ka...@op... || 1-866-677-4546

[relayfs-devel] Re: diskstat 0.1: simple tool to study io patterns via relayfs

[bert h. <ber...@ne...>]

On Mon, Jul 25, 2005 at 03:56:48AM -0400, Sonny Rao wrote:
> Hi, I had some trouble compiling it, I figured out that one needs
> libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1
> don't want to compile it while g++-3.3.5 works.  (FYI, all of these were
> Ubuntu versions)

Yes, you are right. I'll fix the Boost thing, but it really should compile
using all those gcc's. Would you mind sending me the errors you get with the
other compilers (privately)?

> You might want to document some of this in the README :)

This is the least of what needs fixing hehe. Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

[relayfs-devel] Re: diskstat 0.1: simple tool to study io patterns via relayfs

[Sonny R. <so...@bu...>]

On Sun, Jul 24, 2005 at 03:07:30AM +0200, bert hubert wrote:
> It is with distinct lack of pride that I release version 0.1 of diskstat
> 'Geeks in Black Thorn', a tool that allows you to generate the kinds of
> graphs as presented in my OLS talk 'On faster application startup times:
> Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is
> because this release is more a promise of what is to come than how things
> should be.
> 
> The presentation, paper, and software can be found on
> http://ds9a.nl/diskstat and
> http://ds9a.nl/diskstat/diskstat-0.1.tar.gz
> 
> >From the README:
> The quality of this code is abysmal, for which I squarely blame the fun
> people at OLS who've been keeping me from my code!
> (...)
> The next version will be based on k/jprobes, and will make better use of
> relayfs features. This also means you won't have to patch your kernel
> anymore, as long as you compiled with kprobes support.

Hi, I had some trouble compiling it, I figured out that one needs
libboost, but then I've also discovered that g++-3.4.4 and g++-4.0.1
don't want to compile it while g++-3.3.5 works.  (FYI, all of these were
Ubuntu versions)

You might want to document some of this in the README :)

Thanks,
Sonny

[relayfs-devel] diskstat 0.1: simple tool to study io patterns via relayfs

[bert h. <ber...@ne...>]

It is with distinct lack of pride that I release version 0.1 of diskstat
'Geeks in Black Thorn', a tool that allows you to generate the kinds of
graphs as presented in my OLS talk 'On faster application startup times:
Cache stuffing, seek profiling, adaptive preloading'. The lack of pride is
because this release is more a promise of what is to come than how things
should be.

The presentation, paper, and software can be found on
http://ds9a.nl/diskstat and
http://ds9a.nl/diskstat/diskstat-0.1.tar.gz

From the README:
The quality of this code is abysmal, for which I squarely blame the fun
people at OLS who've been keeping me from my code!
(...)
The next version will be based on k/jprobes, and will make better use of
relayfs features. This also means you won't have to patch your kernel
anymore, as long as you compiled with kprobes support.

Sample command lines:
   # mkdir /relay
   # mount -t relayfs none /relay
   # ./dumpdiskstat /relay/diskstat0  > dump

   This will output something like:
   I think we skipped at 90867, ret=0
   I think we hit end at 143016, ret=-1
   I think we hit the break again 90867, ret=0

 Process the stats.
   $ ./dswalk < dump

   It will print out huge latencies encountered:

>  Large latency 163.352 on line 14146
   Total read started: 33888768, total ended: 33888768
   Total write started: 1372160, total ended: 1372160
   Waiting time: 10.695 seconds

 Make pretty plots
   gnuplot
   plot 'startplaces.dat', 'headplaces.dat'
   plot 'inflight.dat'

Continue reading on http://ds9a.nl/diskstat/README

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services