0

I am trying to edit the linux kernel. I want some information to be written out to a file as a part of the debugging process. I have read about the printk function. But i would like to add text to a particular file (file other from the default files that keep debug logs). To cut it short: I would kind of like to specify the "destination" in the printk function (or at least some work-around it)

How can I achieve this? Will using fwrite/fopen work (if yes, will it work without causing much overhead compared to printk, since they are implemented differently)?

What other options do i have?

user1836386
  • 57
  • 1
  • 8
  • Destinations (or sinks) for log messages are supposed to be handled in user space. Logging daemons like `syslog-ng` etc already do that (you will notice multiple files in your `/var/log` directory). Is there a reason you can't do the same? – Michael Foukarakis Sep 08 '14 at 08:27
  • It seems a bad idea. Inside the kernel you should not rely on some directory structure or specific file system (except special kernel file systems). The printk function is meant to handle such case. I suggest you use printk and then post-process the log file using some bash script. – GHugo Sep 08 '14 at 08:43
  • Hi. Thanks for replying. I am kind of a newbie here (this is my first time with the kernel) and it quite didnt strike me to post-process the log files or to use syslog-ng! Thanks for pointing it out to me! – user1836386 Sep 08 '14 at 08:45
  • In that case i would like to know, how do i filter out the text that i have added from the rest of the log? Can i give some tag (unique only to me) in the printk function? – user1836386 Sep 08 '14 at 08:47
  • Yes, you can do that. Also see [this question](http://serverfault.com/q/612589) for some examples on how to use logging daemons to match that text and log it to the file you want. – Michael Foukarakis Sep 08 '14 at 10:01

1 Answers1

1

Using fopen and fwrite will certainly not work. Working with files in kernel space is generally a bad idea.

It all really depends on what you are doing in the kernel though. In some configurations, there may not even be a hard disk for you to write to. If however, you are working at a stage where you can have certain assumptions about the running kernel, you probably actually want to write a kernel module rather than edit the kernel itself. For all you care, a kernel module is just as good as any other part of the kernel, but they are inserted when the kernel is already up and running.

You may also be thinking of doing so for debugging, or have output of a kernel-level application (e.g. an application that you are forced to run at kernel level for real-time constraints etc). In that case, kio may be of interest to you, but if you want to use it, do make sure you understand why.

kio is a library I wrote just for those "kernel-level applications", which makes a kernel module see a /proc file as if it's a user of it (rather than a provider). To make it work, you should have a user-space application also opening that virtual file and redirect it to wherever you want to write your log. Something along the lines of opening the file with kopen in write mode and in user space tell cat /proc/your_file > ~/log_file.

Note: I still recommend printk unless you really know what you are doing. Since you are thinking of fopen in kernel space, I don't think you really know what you are doing.

Shahbaz
  • 46,337
  • 19
  • 116
  • 182
  • The real goal is to write something to some file (any file), each time a process is forked (that is, a new process is created) – user1836386 Sep 09 '14 at 21:47
  • @user1836386, that doesn't sound like information you'd need to be persistent in case of a crash, am I right? In that case I suggest you keep that information in memory (using `vmalloc`), and since that information has a uniform structure (i.e. it's an array of structs), use a _seq file_ to output them on a `/proc` file on demand. Anyone who needs that information can retrieve it from the `/proc` file. – Shahbaz Sep 10 '14 at 08:39
  • Alternatively, to make sure you don't indefinitely grow the memory, only output the new information since last update. That way, a separate (userland) process can periodically read the `/proc` file and append it to whatever file you want. – Shahbaz Sep 10 '14 at 08:39
  • So how do I monitor the /proc in order to only append only when changes are seen? Using something like string compare would be too much of a load, wouldn't it? – user1836386 Sep 11 '14 at 20:35
  • No you don't do that. On every read, read everything and append to file. The kernel module itself can throw away what is already read. – Shahbaz Sep 12 '14 at 07:29
  • Hi! I am not quite sure how to do that. I played around with the "cat" command but it does not seem to skip the lines that are already there... It appends everything from the input file... Or Overwrites the whole output file – user1836386 Sep 12 '14 at 10:06
  • The `/proc` file is like the other end of a file, for example impersonating a hard disk. _You_ decide what comes out of it. `cat` just reads the file, thinking it's written on a hard disk or whatever and on the other end, the kernel calls your callback which provides whatever data you want to `cat`. _You_ decide if you want to give all the data, or only the new ones. – Shahbaz Sep 12 '14 at 11:42
  • I suggest experimenting with `/proc` files to learn more. For example, try an exercise where you output a single number (globally defined) and increment it on each call. Every `cat` of that `/proc` file would then give you a new value. For your case, you have an circular array of data with two indices on it saying where new data begins and where is the end of data. Once you output all data, you just set the index of `new_data` to `end_of_data`. Once more data is generated, `end_of_data` would move forward and next read of `/proc` file would just give you new values. – Shahbaz Sep 12 '14 at 11:44
  • Hey shabaz! thanks so much for giving the direction! I will definitely play around with it and hope to be an expert like you someday! Really appreciate your patience! :) – user1836386 Sep 12 '14 at 11:57