Re: Copying kernel module error messages to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Sep 14, 2009 at 3:32 PM, Leonidas . <leonidas137@xxxxxxxxx> wrote:


On Mon, Sep 14, 2009 at 3:28 PM, Leonidas . <leonidas137@xxxxxxxxx> wrote:


On Mon, Sep 14, 2009 at 2:46 PM, karunakar rao <karunakar.santhu@xxxxxxxxx> wrote:
hi leo
maintain circular buffer in module, so that if user doesn't access for days its going to be automatically discarded.I think printk also use same kind of mechanism which dumps data into cirbuffer.
 
thanks,
karuna.

On Mon, Sep 14, 2009 at 2:41 PM, Leonidas . <leonidas137@xxxxxxxxx> wrote:


On Mon, Sep 14, 2009 at 2:30 PM, karunakar rao <karunakar.santhu@xxxxxxxxx> wrote:
hi leo
you can maintain buffer in your module to log errors.When user tries to access /proc you can print all those from your buffer.
 
Thanks,
karuna.

On Mon, Sep 14, 2009 at 1:22 PM, Leonidas . <leonidas137@xxxxxxxxx> wrote:


Hi List

I have written a kernel module which implements a char device. An userspace app
is supposed to get data from my module and then dump it into a file for further processing.

The kind of data which kernel module is going to pass to userspace is going to be a 4K buffer,
and the data traffic is not going to be really heavy, meaning may be a 4K buffer every 1 min or so.
I am not very sure though, but certainly not heavy traffic the way they describe for network traffic etc.

And this data needs to be logged to a file either from kernel or userspace and an userspace all will work
on that data. This data needs to be logged as soon as it arrives meaning, I might not be able to write it to
/proc since from module I can update /proc only when user actually accesses it. This data needs to be
static in nature, meaning I get one error and I write it to a file somehow and user can see it anytime.
 
I hope I have described the situation clearly. I have explored some mechanism like ioctls, mmaping the
kernel buffer etc but all these would require the user module to poll or notified somehow by kernel that
the data is available. I dont want the user module to poll.


-Leo.



Pei Lin,

I am not limiting my solution by using a law or what someone says. But I think it is very important to 
follow the spirit of environment/OS/arch you are working on and come up with the best possible solution.
As you correctly mention we can hack around and achieve the same functionality but I would rather do these
kind of experiments for fun or to show my friends that the kernel can be hacked these ways, but certainly not
in a system which is supposed to be a production system. I appreciate your thoughts and I am sure many times
one stumbles upon real cool things which change course of nature and are reasons for radical changes in
various subsystems. But I think this is not one of them, this has been discussed over and over again and there
are standard interfaces defined. My questions is more about the design part not about how I can hack and get
the stuff done.

Karuna,
I had thought about this solution i.e. maintain a buffer in module and dump it whenever user wants, only
issue is my module will keep consuming memory here. I msg buffers can be freed once logged but how about
a case where user does not request for few days? The amount of memory my module is going to consume will be
unacceptable.

-Leo


Sorry I did not mention it earlier, I can not discard any error message logged, meaning these are error messages
and might crash my system after a long time. I need to to be able to see all these messages till I restart my module.

_Leo.


Basically, I am quite tight on memory and I would like to convery error messages to user as soon as any
error condition is hit. So my module cant keep even 10 error msg which will eat up 10 pages.

_Leo



Looks like some of the replys didn't get delivered to the list. Please refer the thread for someof the interactions.

Isn't debugfs the right thing to use here? Anyone? Please enlighten.

_Leo

 


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux