mpc / linux kernel - user space
Hello,
I tried to make use of wake_up_interruptible(wq) in my module as
following (I just wanted to test if I'm using it correctly):
If I'm doing insmod, the module blocks in the wake_up_interruptible call.
Does somebody know why? Maybe because there is no process sleeping? How do
I check this?
DECLARE_WAIT_QUEUE_HEAD(wq);
int sleepy_init(void) {
test_file = create_proc_entry("test", 0666, NULL);
if(test_file == NULL) {
return -ENOMEM;
}
wake_up_interruptible(&wq);
return 0;
}
void sleepy_cleanup(void) {
remove_proc_entry("test", NULL);
}
module_init(test_init);
module_exit(test_cleanup);
Best regards,
Juergen
On Fri, 2003-11-28 at 10:21, Aain_Devarenne%ZODIAC at zodiac.com wrote:
> Hi everybody
>
> I 'm pending on the same problem as Juergen,
> - How can a User Space Thread Wait for a signaling event set by KERNEL ?
e.g. issue a read on some device driver (/dev/
which will block until an interrupt has occured.
something like this:
DECLARE_WAIT_QUEUE_HEAD(mydriver_queue);
ssize_t mydriver_read(
struct file *filp,
char *buf,
size_t count,
loff_t *f_pos)
{
/* wait on interrupt */
while (1) {
interruptible_sleep_on(&mydriver_queue);
if (signal_pending (current)) /* a signal arrived */
return -ERESTARTSYS; /* tell the fs layer to handle it */
else break;
}
return 0;
}
void mydriver_irqhandler(unsigned long arg)
{
wake_up_interruptible(&mydriver_queue);
}
Jaap-Jan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
On Fri, 2003-11-28 at 16:42, Dan Malek wrote: > Jaap-Jan Boor wrote: > > > If you want to send a signal to user code, you can use kill_proc() > > I think. > > IMHO, trying to use signals to propagate a hardware interrupt to a > user application is complicated and has design flaws (what happens > if the application "misses" an interrupt or gets blocked for some > reason). Fortunately I never used it (that's the 'I think') > > A couple of other methods that I find simple and use extensively > are multi-threading the application and then using a different > minor ID device to wait on a read() or ioctl() to simply return. > The driver just uses the standard sleep/wakeup mechanisms to > synchronize with the application. > > Another, and I think most useful, method is to implement a select/poll > entry point in the driver. It provides the most flexibility when > waiting for various events, plus provides a timeout should something > fail to function properly. Yes, especially the timeout is nice as 'this should never happen' failures never happens except with the customer Jaap-Jan > > > -- Dan > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Hi, Write an ioctl method in your module. And provide provision in ioctl to take a function pointer & store it. Whenever there is an timer interrupt, check for this pointer, if not NULL , then you can call the function. When your application comes up, makesure u pass the command to ioctl of your module with the function pointer as arg. Hope this help ! Regards Sampath - Original Message - From: Juergen Oberhofer <[EMAIL PROTECTED]> To: Sent: Thursday, November 27, 2003 9:37 PM Subject: mpc / linux kernel - user space > > Hi, > > I have a module and an application program in user space: > > The Module performs the following task: at init it initializes the cpm > timer register of the mpc823, > such that an interrupt is generated every x microseconds. Thus, I > installed an interrupt handling function f that handles the timer > interrupts. > > My problem is that the module / the interrupt handling function should > execute a procedure defined in the application program. How can I pass a > pointer (which points to that function) from the appl.program to the > module, such that the handler can execute this function every x > milliseconds? I thought to create a procedure in the module that accepts > a function pointer as argument. But how can I achieve, that this module > procedure is visible to the application program? Does somebody have a > suggestion or know another way to do it? > > Regards, > Juergen > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Réf. : Re: mpc / linux kernel - user space
On Fri, 2003-11-28 at 10:21, Aain_Devarenne%ZODIAC at zodiac.com wrote:
> Hi everybody
>
> I 'm pending on the same problem as Juergen,
> - How can a User Space Thread Wait for a signaling event set by KERNEL ?
e.g. issue a read on some device driver (/dev/
which will block until an interrupt has occured.
something like this:
DECLARE_WAIT_QUEUE_HEAD(mydriver_queue);
ssize_t mydriver_read(
struct file *filp,
char *buf,
size_t count,
loff_t *f_pos)
{
/* wait on interrupt */
while (1) {
interruptible_sleep_on(&mydriver_queue);
if (signal_pending (current)) /* a signal arrived */
return -ERESTARTSYS; /* tell the fs layer to handle it */
else break;
}
return 0;
}
void mydriver_irqhandler(unsigned long arg)
{
wake_up_interruptible(&mydriver_queue);
}
Jaap-Jan
> - Can an IOCTL return pending, and then do a completion after the event ?
> - Can we pass an Handle by IOCTL to Kernel from user space ?
>
> Ps: Calling a pointeur in UserSpce seems a bit weird and unsecure !!!
>
>
> Regards Alain Devarenne
>
>
>
>
> Hi Juergen,
>
> That's normally not something you do and I don't know if it's possible.
> Application code normally communicates with your driver code using
> system
> calls (read/write). So either your appl procedure must be part
> of your module, or you must signal e.g. a user thread the timer
> interrupt happened, so the thread can execute that code.
> Hope this helps,
>
> Jaap-Jan
>
>
> On 27-nov-03, at 17:07, Juergen Oberhofer wrote:
>
> >
> > Hi,
> >
> > I have a module and an application program in user space:
> >
> > The Module performs the following task: at init it initializes the cpm
> > timer register of the mpc823,
> > such that an interrupt is generated every x microseconds. Thus, I
> > installed an interrupt handling function f that handles the timer
> > interrupts.
> >
> > My problem is that the module / the interrupt handling function should
> > execute a procedure defined in the application program. How can I pass
> > a
> > pointer (which points to that function) from the appl.program to the
> > module, such that the handler can execute this function every x
> > milliseconds? I thought to create a procedure in the module that
> > accepts
> > a function pointer as argument. But how can I achieve, that this module
> > procedure is visible to the application program? Does somebody have a
> > suggestion or know another way to do it?
> >
> > Regards,
> > Juergen
> >
> >
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Jaap-Jan Boor wrote: > If you want to send a signal to user code, you can use kill_proc() > I think. IMHO, trying to use signals to propagate a hardware interrupt to a user application is complicated and has design flaws (what happens if the application "misses" an interrupt or gets blocked for some reason). A couple of other methods that I find simple and use extensively are multi-threading the application and then using a different minor ID device to wait on a read() or ioctl() to simply return. The driver just uses the standard sleep/wakeup mechanisms to synchronize with the application. Another, and I think most useful, method is to implement a select/poll entry point in the driver. It provides the most flexibility when waiting for various events, plus provides a timeout should something fail to function properly. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Réf. : Re: mpc / linux kernel - user space
Hi everybody I 'm pending on the same problem as Juergen, - How can a User Space Thread Wait for a signaling event set by KERNEL ? - Can an IOCTL return pending, and then do a completion after the event ? - Can we pass an Handle by IOCTL to Kernel from user space ? Ps: Calling a pointeur in UserSpce seems a bit weird and unsecure !!! Regards Alain Devarenne Hi Juergen, That's normally not something you do and I don't know if it's possible. Application code normally communicates with your driver code using system calls (read/write). So either your appl procedure must be part of your module, or you must signal e.g. a user thread the timer interrupt happened, so the thread can execute that code. Hope this helps, Jaap-Jan On 27-nov-03, at 17:07, Juergen Oberhofer wrote: > > Hi, > > I have a module and an application program in user space: > > The Module performs the following task: at init it initializes the cpm > timer register of the mpc823, > such that an interrupt is generated every x microseconds. Thus, I > installed an interrupt handling function f that handles the timer > interrupts. > > My problem is that the module / the interrupt handling function should > execute a procedure defined in the application program. How can I pass > a > pointer (which points to that function) from the appl.program to the > module, such that the handler can execute this function every x > milliseconds? I thought to create a procedure in the module that > accepts > a function pointer as argument. But how can I achieve, that this module > procedure is visible to the application program? Does somebody have a > suggestion or know another way to do it? > > Regards, > Juergen > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Hi Juergen, What I more ment with 'signal your application process' is you have a user thread block waiting in the read() system call of your driver and your driver will wake up that blocking read, so the application thread returns from read. If you want to send a signal to user code, you can use kill_proc() I think. Jaap-Jan On Thu, 2003-11-27 at 19:08, Juergen Oberhofer wrote: > Thank you! You mean that the application should install a signal handler > and > the module sends on every interrupt a signal to the application process. > Do you know, Which function does exist to send a signal? I guess, the > module has to know the pid of the application process? How can the module > be informed about it? > Regards, > Juergen > > On Thu, 27 Nov 2003, Jaap-Jan Boor wrote: > > > Hi Juergen, > > > > That's normally not something you do and I don't know if it's possible. > > Application code normally communicates with your driver code using > > system > > calls (read/write). So either your appl procedure must be part > > of your module, or you must signal e.g. a user thread the timer > > interrupt happened, so the thread can execute that code. > > Hope this helps, > > > > Jaap-Jan > > > > > > On 27-nov-03, at 17:07, Juergen Oberhofer wrote: > > > > > > > > Hi, > > > > > > I have a module and an application program in user space: > > > > > > The Module performs the following task: at init it initializes the cpm > > > timer register of the mpc823, > > > such that an interrupt is generated every x microseconds. Thus, I > > > installed an interrupt handling function f that handles the timer > > > interrupts. > > > > > > My problem is that the module / the interrupt handling function should > > > execute a procedure defined in the application program. How can I pass > > > a > > > pointer (which points to that function) from the appl.program to the > > > module, such that the handler can execute this function every x > > > milliseconds? I thought to create a procedure in the module that > > > accepts > > > a function pointer as argument. But how can I achieve, that this module > > > procedure is visible to the application program? Does somebody have a > > > suggestion or know another way to do it? > > > > > > Regards, > > > Juergen > > > > > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
In message <006801c3b571$408bc6e0$c314a8c0 at cm> you wrote: > > Write an ioctl method in your module. And provide provision in ioctl to take > a function pointer & store it. What a bogus advice. You CANNOT call user space code from kernel context. [And actually you don't want to.] Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Human beings were created by water to transport it uphill. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Thank you! You mean that the application should install a signal handler and the module sends on every interrupt a signal to the application process. Do you know, Which function does exist to send a signal? I guess, the module has to know the pid of the application process? How can the module be informed about it? Regards, Juergen On Thu, 27 Nov 2003, Jaap-Jan Boor wrote: > Hi Juergen, > > That's normally not something you do and I don't know if it's possible. > Application code normally communicates with your driver code using > system > calls (read/write). So either your appl procedure must be part > of your module, or you must signal e.g. a user thread the timer > interrupt happened, so the thread can execute that code. > Hope this helps, > > Jaap-Jan > > > On 27-nov-03, at 17:07, Juergen Oberhofer wrote: > > > > > Hi, > > > > I have a module and an application program in user space: > > > > The Module performs the following task: at init it initializes the cpm > > timer register of the mpc823, > > such that an interrupt is generated every x microseconds. Thus, I > > installed an interrupt handling function f that handles the timer > > interrupts. > > > > My problem is that the module / the interrupt handling function should > > execute a procedure defined in the application program. How can I pass > > a > > pointer (which points to that function) from the appl.program to the > > module, such that the handler can execute this function every x > > milliseconds? I thought to create a procedure in the module that > > accepts > > a function pointer as argument. But how can I achieve, that this module > > procedure is visible to the application program? Does somebody have a > > suggestion or know another way to do it? > > > > Regards, > > Juergen > > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Hi Juergen, That's normally not something you do and I don't know if it's possible. Application code normally communicates with your driver code using system calls (read/write). So either your appl procedure must be part of your module, or you must signal e.g. a user thread the timer interrupt happened, so the thread can execute that code. Hope this helps, Jaap-Jan On 27-nov-03, at 17:07, Juergen Oberhofer wrote: > > Hi, > > I have a module and an application program in user space: > > The Module performs the following task: at init it initializes the cpm > timer register of the mpc823, > such that an interrupt is generated every x microseconds. Thus, I > installed an interrupt handling function f that handles the timer > interrupts. > > My problem is that the module / the interrupt handling function should > execute a procedure defined in the application program. How can I pass > a > pointer (which points to that function) from the appl.program to the > module, such that the handler can execute this function every x > milliseconds? I thought to create a procedure in the module that > accepts > a function pointer as argument. But how can I achieve, that this module > procedure is visible to the application program? Does somebody have a > suggestion or know another way to do it? > > Regards, > Juergen > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Hi, I have a module and an application program in user space: The Module performs the following task: at init it initializes the cpm timer register of the mpc823, such that an interrupt is generated every x microseconds. Thus, I installed an interrupt handling function f that handles the timer interrupts. My problem is that the module / the interrupt handling function should execute a procedure defined in the application program. How can I pass a pointer (which points to that function) from the appl.program to the module, such that the handler can execute this function every x milliseconds? I thought to create a procedure in the module that accepts a function pointer as argument. But how can I achieve, that this module procedure is visible to the application program? Does somebody have a suggestion or know another way to do it? Regards, Juergen ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc / linux kernel - user space
Juergen Oberhofer wrote: >>>My problem is that the module / the interrupt handling function should >>>execute a procedure defined in the application program. How can I pass >>>a pointer (which points to that function) from the appl.program to the >>>module, such that the handler can execute this function every x >>>milliseconds? I thought to create a procedure in the module that >>>accepts >>>a function pointer as argument. But how can I achieve, that this module >>>procedure is visible to the application program? >>> ... >> That's normally not something you do and I don't know if it's possible. >> Application code normally communicates with your driver code using >> system >> calls (read/write). So either your appl procedure must be part >> of your module, or you must signal e.g. a user thread the timer >> interrupt happened, so the thread can execute that code. > > Thank you! You mean that the application should install a signal handler > and the module sends on every interrupt a signal to the application process. Although you could do it that way, it might be better to use a unix domain or a netlink socket, and have the kernel module send a message which the user program reads via the 'read' system call. For what it's worth, netlink sockets turn out to be pretty easy to use. See http://www.cs.auc.dk/~fleury/netkeeper/ for one example. Most of the complexity in programs that use netlink are because they're trying to communicate routing information. If you just want to send your own messages, create the netlink socket with type NETLINK_USERSOCK and don't worry about the fancy stuff. - Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
