user space program from keyboard driver

user space program from keyboard driver

[Payasam Manohar]

hai all,
    I am a newbie to kernel, I want to work on linux kernel modules.
My task is to call a user program from keyboard driver under certain 
conditions. I know that we can call user program using 
call_usermodehelper(), but we can not call it direcly from driver as it is 
a interrupt context. So we need to call using schedule_work(). But I need 
more clarification on these points. How to call user program from the 
keyboard driver. Please give ur ideas for doing this.

Any small help is appreciated.


Please cc ur replies to my mail id.


   Thanks&Regards,

   P.Manohar,

Re: user space program from keyboard driver

[linux-os]

On Mon, 28 Feb 2005, Payasam Manohar wrote:

> hai all,
>   I am a newbie to kernel, I want to work on linux kernel modules.
> My task is to call a user program from keyboard driver under certain 
> conditions. I know that we can call user program using call_usermodehelper(), 
> but we can not call it direcly from driver as it is a interrupt context. So 
> we need to call using schedule_work(). But I need more clarification on these 
> points. How to call user program from the keyboard driver. Please give ur 
> ideas for doing this.
>
> Any small help is appreciated.
>

You don't call a user-mode program from a driver period. It is
possible to screw with kernel internals in such as way to do this,
then unscrew what you've screwed up (sometimes) then state; "See
it can be done.....!". Wrong! Learn that the kernel is designed
to perform tasks on behalf of a user-mode caller. That's what it's
designed for. The kernel doesn't have its own context which is
needed to open files, etc. It has to steal somebody else's context
to do that. It results in a very precarious situation where the
stolen task's context can exit at any time and leave the kernel
in a mess or one steals the context of `init` assuming that
it's not going to quit. The result is a kludge which is
filthy with races.

You should NEVER design anything that runs in the kernel that
expects to call user-mode code. The usermodehelper() code
was used ONLY to get a module for automatic loading of modules.
Even that shouldn't exist and it doesn't need to exist for
the purpose being used. It creates a 'child' of the kernel-
event daemon. If that code was done correctly, none of that
bloat would be in the kernel and fewer persons might expect
to make calls to user-mode code.

The CORRECT design for a user-mode helper requires a user-mode
task called a daemon. That daemon normally sleeps. You can
usually see a lot of such daemons when you execute `ps lae`.
So, you write a program that waits for a signal to wake it
up, perhaps using select() or poll(). It has opened your
driver that exists in the kernel. When your driver wants
your user-mode helper to do something it wakes it up, perhaps
using wake_up_interruptible() or other such kernel functions.
The user-mode helper might make an ioctl() call to find out
what the driver wants done (like reading/writing file data).
The data goes across the driver/user I/O interface like
read() write() or ioctl(). The actual file is open/created/
read/write/closed by the user-mode daemon.

You can wake up a user-mode task from within an interrupt.
However, it only starts executing when it's safe to do
so. In other words, you will NEVER do anything with files
inside an interrupt-service routine.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: user space program from keyboard driver

[Payasam Manohar]

>> hai all,
>>   I am a newbie to kernel, I want to work on linux kernel modules.
>> My task is to call a user program from keyboard driver under certain 
>> conditions. I know that we can call user program using 
>> call_usermodehelper(), but we can not call it direcly from driver as it is 
>> a interrupt context. So we need to call using schedule_work(). But I need 
>> more clarification on these points. How to call user program from the 
>> keyboard driver. Please give ur ideas for doing this.
>> 
>> Any small help is appreciated.
>> 
>
> You don't call a user-mode program from a driver period. It is
> possible to screw with kernel internals in such as way to do this,
> then unscrew what you've screwed up (sometimes) then state; "See
> it can be done.....!". Wrong! Learn that the kernel is designed
> to perform tasks on behalf of a user-mode caller. That's what it's
> designed for. The kernel doesn't have its own context which is
> needed to open files, etc. It has to steal somebody else's context
> to do that. It results in a very precarious situation where the
> stolen task's context can exit at any time and leave the kernel
> in a mess or one steals the context of `init` assuming that
> it's not going to quit. The result is a kludge which is
> filthy with races.
>
> You should NEVER design anything that runs in the kernel that
> expects to call user-mode code. The usermodehelper() code
> was used ONLY to get a module for automatic loading of modules.
> Even that shouldn't exist and it doesn't need to exist for
> the purpose being used. It creates a 'child' of the kernel-
> event daemon. If that code was done correctly, none of that
> bloat would be in the kernel and fewer persons might expect
> to make calls to user-mode code.
>
> The CORRECT design for a user-mode helper requires a user-mode
> task called a daemon. That daemon normally sleeps. You can
> usually see a lot of such daemons when you execute `ps lae`.
> So, you write a program that waits for a signal to wake it
> up, perhaps using select() or poll(). It has opened your
> driver that exists in the kernel. When your driver wants
> your user-mode helper to do something it wakes it up, perhaps
> using wake_up_interruptible() or other such kernel functions.
> The user-mode helper might make an ioctl() call to find out
> what the driver wants done (like reading/writing file data).
> The data goes across the driver/user I/O interface like
> read() write() or ioctl(). The actual file is open/created/
> read/write/closed by the user-mode daemon.
>

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.

Re: user space program from keyboard driver

[Helge Hafting]

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 

Re: user space program from keyboard driver

[Lee Revell]

On Mon, 2005-02-28 at 21:24 +0530, Payasam Manohar wrote:
> hai all,
>     I am a newbie to kernel, I want to work on linux kernel modules.
> My task is to call a user program from keyboard driver under certain 
> conditions. I know that we can call user program using 
> call_usermodehelper(), but we can not call it direcly from driver as it is 
> a interrupt context. So we need to call using schedule_work(). But I need 
> more clarification on these points. How to call user program from the 
> keyboard driver. Please give ur ideas for doing this.
> 

Are you just trying to write a keystroke logger?

Lee

Re: user space program from keyboard driver

[Payasam Manohar]

Thanks.My work is not writing keystroke logger, I know about it, but I 
want to call some other program which will run in bash ,and get some data 
from user mode and return to kernel mode on demand,
which can be called from keyboard driver.





   Thanks&Regards,

   P.Manohar,


On Mon, 28 Feb 2005, Lee Revell wrote:

> On Mon, 2005-02-28 at 21:24 +0530, Payasam Manohar wrote:
>> hai all,
>>     I am a newbie to kernel, I want to work on linux kernel modules.
>> My task is to call a user program from keyboard driver under certain
>> conditions. I know that we can call user program using
>> call_usermodehelper(), but we can not call it direcly from driver as it is
>> a interrupt context. So we need to call using schedule_work(). But I need
>> more clarification on these points. How to call user program from the
>> keyboard driver. Please give ur ideas for doing this.
>>
>
> Are you just trying to write a keystroke logger?
>
> Lee
>