Python way to printk?

[Thomas Jollans]

On 06/09/2010 11:40 PM, J wrote:
> Does anyone know of a way, or have a recipe, to do a linux printk
> equivalent in Python?
> 
> I've been googling for a while and not finding anything useful.
> 
> The nutshell version of this is that I need to write a routine for a
> test tool I'm working on that will time the amount of time used to
> take a system and go from Live to Suspended and then from Suspended to
> Live.

as "News123" has said, it's probably not possible, simply because
(AFAIK) printk is a kernel-internal function. Even if it were callable
from user space, it would be a system call, so ctypes probably wouldn't
help you, since that operates on shared libraries (correct me if I'm
wrong, anyone)

But how about - the syslog. I expect your syslog daemon copies kernel
messages to the log, and you can write to that.

> 
> I can get all the times I need from the kernel message buffer (via
> dmesg) but one of the test cases involves doing 30 suspend/resume
> cycles, so I'll end up having to parse and weed out a lot of redundant
> data.
> 
> One idea I had was to just flush the buffer (calling dmesg -c) but
> that's not the nicest way of doing things on an end user's system.
> 
> SO, the thought I had was to just inject a marker like "START SUSPEND
> TEST hash" where hash is a unique identifier for that test run, either
> the number of the run (1 - 30) or a timestamp or whatever... it just
> has to be unique
> and then inject a "FINISHED SUSPEND TEST has" marker after the system
> is fully live.
> 
> THEN I could just look for those two markers and parse the data in
> between them for the timestamps I need.
> 
> but I can't find any way so far, in python to write kernel messages.
> Perhaps this is something for ctypes? (though I'm trying to keep from
> introducing non-python code if at all possible) and I've never used
> ctypes before and have no real idea how to use them (perhaps this
> would be a good, easy way to learn?)
> 
> I'm going to start looking at ctypes after sending this and maybe
> learn something new today, but I also wanted to ask the list for
> suggestions as well.
> 
> Cheers,
> 
> Jeff
> 
> And yes, this is not something that would be portable to a non-Linux
> OS, but that's ok, because this is strictly a Linux tool anyway.