mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Payasam Manohar <pmanohar@lantana.cs.iitm.ernet.in>
Cc: linux-os <linux-os@analogic.com>, linux-kernel@vger.kernel.org
Subject: Re: user space program from keyboard driver
Date: Wed, 2 Mar 2005 20:44:20 +0100	[thread overview]
Message-ID: <20050302194420.GA9839@hh.idb.hist.no> (raw)
In-Reply-To: <Pine.LNX.4.60.0503012031560.13310@lantana.cs.iitm.ernet.in>

On Tue, Mar 01, 2005 at 08:38:01PM +0530, Payasam Manohar wrote:
> 
> 
> Hai thank u for ur information. If possible can u please give some 
> reference for the above task of creating a daemon and waking up in demand.
> 
> Is it possible to call a daemon from keyboard driver on pressing certain 
> key, if so how to kill the daemon from the driver itself with some other 
> condition.

I don't know exactly what you want to do, but there is asimple
interface for kernelspace to userspace communication, and that is
to make a character device driver.

You needed to have the kernel ask userspace something and have
userspace report back an answer?  Simple:

1. Userspace program opens your "kernel communication" device
2. The program, or daemon, tries to read from the device.
3. The program will block, because the kernel doesn't have data for
   it at the moment.
4. When the kernel needs data, it writes something to the device.
   If you need to pass information to the daemon program, use thie
   opportunity to write that information.
5. The daemon wakes up because it got data.  It interprets the data,
   and does whatever you want it to do.  When the program have an
   answer to the kernel, it writes the answer into the device.
6. The kernel code gets the answer, in the form of a call into
   the part of the device driver that handles writes from userspace.
   Now the kernel can utilize the information.
7. The daemon can run in a loop, issuing a new read from the device in case
   its services will be needed again.

Thare are variations on this theme.  You may not want to create a new
device if the kernel code that needs this daemnon service is a device 
driver already, for example.  In that case you may want to use an ioctl 
interface for  that device instead.  Note that ioctl's isn't all that 
popular though.

Helge Hafting 

  reply	other threads:[~2005-03-02 19:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-28 15:54 Payasam Manohar
2005-02-28 16:35 ` linux-os
2005-03-01 15:08   ` Payasam Manohar
2005-03-02 19:44     ` Helge Hafting [this message]
2005-02-28 21:21 ` Lee Revell
2005-03-01  3:41   ` Payasam Manohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050302194420.GA9839@hh.idb.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    --cc=pmanohar@lantana.cs.iitm.ernet.in \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®