Hello... > The first question is: Can I use an internal linux scheduler (in 2.6) > instead of using this infinite loop? I would like that kernel will > care about execution of specified task at specified time by himself. > For example like this: when time point comes, the kernel wake up my > application, gives them execution control and after execution my > application will sleep until next event. read Linux Device Driver 3rd edition about how to create timer....I think you will complete information there. In your application side, you can do a blocking read on self created /proc entry and this /proc entry does nothing except awaiting an event in (un)interruptible style. Maybe there are other ideas... > Of cource, realtime systems (like RTLinux and rtoi)can be used > instead, but i really don't need them - their perfomance slower and > they are hard real-time (it means that missing an event is a > failure)... I realy don't need so serious stuff. And also i have only > one "Real-Time" thread. How do it best? Set your application on highest available priority setting (nice -19)? or maybe using soft real time priority like the one created by Ingo Molnar or SCHED_ISO patch by Con Kolivas? > So, my next question > is : How can kernel driver inform userspace application the fastest > way? Now i use only signals (SIGUSR1 and SIGUSR2), it's good enoung, > but i want more :) Actually, IMHO delivering signal is fast enough..the problem is how fast the scheduler select your process to get back to the run queue (if it was in sleeping) state and actually run it. That's why I suggest to set your process on highest priority available. Enabling kernel preemption might help too (in 2.6 this is the default IIRC) > And third question: What is the fastest way to communicate between > kernel and userspace? Now i use ioctl (via special device file, e.g. > /dev/mydevice), but i think that communication through system calls > can be a little bit faster. Is it true? actually, ioctl() is a system call too :) If the system call is utilizing SYSENTER/SYSCALL, it will be a bit faster. But you said, you want to communicate right? that means passing a data, awaiting for certain kernel event, or something else? regards Mulyadi -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
