Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a code which detects GPIO interrupt in a kernel module. Now,I am looking for a mechanism to notify user space upon detecting gpio interrupt from kernel module. Any example / code snippet with certain advantages/disadvantages over different options? I would appreciate your response.
Take a look at the GPIO keyboard driver (drivers/input/keyboard/gpio_keys.c). It is a good starting point for your problem.
In the userspace you then listen (some blocking read for example, or just tail to test) to /dev/input/yourevent for events.
You can send a signal to user space thread from kernel API, which can help u run non-blocking:
send_sig(int sig, struct task_struct *p, int priv)
But there is a limitation: u need to be aware of pid of user thread in Kernel. You can over come this by writing pid of user process via /proc and then kernel reading the pid. With this arrangement, when there is an interrupt, kernel can send signal to user thread. In case your process restarts or gets killed, you will have to update the pid via proc.
If i were you, i would have preferred to do this unless i dont want to transfer data from kernel to user. For data transfer requirement, i would have used Netlink or some other mechanism.
You can:
(1) Send a signal to the user application, or
(2) implement file_operations->poll method, use poll_wait and wait queue to wake user application when interrupt occur.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Thread is formally a sequence of events.
Some of the events mentioned below
Assign to a shared variable
Assign to a local variable
Invoke method
Return from method
So here, It means instruction execution and events are the same or not.
I need to know the difference between the event and instruction execution if they are different?
Can anyone explain what is called an event?
Threads and these events can be seen as state diagrams where threads (programming counter, local variables) are states and events are transitions.
Whenever an event happens thread state may change.
Thanks in advance
Internal event is an instruction execution. External event is a mean of communication between threads. They are implemented by special kinds of instructions, which can safely be executed on parallel threads (CAS, compare-and-set, compare-and-swap). The ulimate goal of external event is to pass signal from one thread to another. Usually it is done using a buffer, that is, one thread puts signal in a buffer, and another thread extracts that signal, waithing if no signals are ready.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
man select
BUGS
Under Linux, select() may report a socket file descriptor as "ready
for reading", while nevertheless a subsequent read blocks. This could
for example happen when data has arrived but upon examination has
wrong checksum and is discarded. There may be other circumstances
in which a file descriptor is spuriously reported as ready. Thus it
may be safer to use O_NONBLOCK on sockets that should not block.
But I see netcat, socat, wget (but not curl) putting FDs without O_NONBLOCK to select or poll.
I've implemented a special library to test apps for this and they are failing...
/* Inspired by seeing a hung wget that was reading from a stale socket and not timing out like it should */
Should I report this as bugs or they are doing it it right?
Possible answers:
"No, blocking FD in poll/select => bug";
"Only AF_INET[6] sockets can misfire on select, so a bug only if a blocking network socket is in poll/select";
"Yes, report bugs only if/when you see a real-world failure because of this" (like in wget).
I'm writing a user space program and a kernel space device driver.
Goal: Once an interrupt occurs, user space program needs to do something quickly.
My naive method: User space program uses ioctl to call wait_event_interruptible(), kernel ISR calls wake_up_interruptible() to wake up user space program. It turns out that it takes too much time from interrupt to user space.
Is there any better way?
Thanks!
There is a similar question asked here:
Notify gpio interrupt to user space from a kernel module
Please check above question. However, i can provide my approach which i suggested there as well.
You can send a signal to user space thread from kernel API, which can help u run non-blocking:
send_sig(int sig, struct task_struct *p, int priv);
You need to be aware of pid of user thread in Kernel. You can over come this by writing pid of user process via /proc and then kernel reading the pid. With this arrangement, when there is an interrupt, kernel can send signal to user thread. In case your process restarts or gets killed, you will have to update the pid via proc. Just for status notification you can use this method; however if you like to transfer data along with status than Netlink or char driver mechanism is good way.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
What is event-driven programming and has event-driven programming anything to do with threading? I came to this question reading about servers and how they handle user requests and manage data. If user sends request, server begins to process data and writes the state in a table. Why is that so? Does server stop processing data for that user and start to process data for another user or processing for every user is run in a different thread (multithread server)?
Event driven programming != Threaded programming, but they can (and should) overlap.
Threaded programming is used when multiple actions need to be handled by a system "simultaneously." I use simultaneously loosely as most OS's use a time sharing model for threaded activity, or at least they do when there are more threads than processors available. Either way, not germane to your Q.
I would use threaded programming when I need an application to do two or more things - like receiving user input from a keyboard (thread 1) and running calculations based upon the received input (thread 2).
Event driven programming is a little different, but in order for it to scale, it must utilize threaded programming. I could have a single thread that waits for an event / interrupt and then processes things on the event's occurrence. If it were truly single threaded, any additional events coming in would be blocked or lost while the first event was being processed. If I had a multi-threaded event processing model then additional threads would be spun up as events came in. I'm glossing over the producer / worker mechanisms required, but again, not germane to the level of your question.
Why does a server start processing / storing state information when an event is received? Well, because it was programmed to. :-) State handling may or may not be related to the event processing. State handling is a separate subject from event processing, just like events are different than threads.
That should answer all of the questions you raised. Jonny's first comment / point is worth heeding - being more specific about what you don't understand will get you better answers.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I'm recompiling my kernel, and I want to choose an I/O scheduler. What's the difference between these?
If you compile them all, you can select at boot time or per-device which scheduler to use. No need to pick at compile time, unless you are targeting an embedded device where every byte counts. See Documentation/block/switching-sched.txt for details on switching per-device or system-wide at boot.
The CFQ scheduler allows you to set priorities via the ionice(1) tool or the ioprio_set(2) system call. This allows giving precedence to some processes or forcing others to do their IO only when the system's block devices are relatively idle. The queues are implemented by segregating the IO requests from processes into queues, and handling the requests from each queue similar to CPU scheduling. Details on configuring it can be found in Documentation/block/cfq-iosched.txt.
The deadline scheduler by contrast looks at all writes from all processes at once; it sorts the writes by sector number, and writes them all in linear fashion. The deadlines means that it tries to write each block before its deadline expires, but within those deadlines, is free to re-arrange blocks as it sees fit. Details on configuring it can be found in Documentation/block/deadline-iosched.txt.
Probably very little in practice.
In my testing, I found that in general NOOP is a bit better if you have a clever RAID controller. Others have reported similar results, but your workload may be different.
However, you can select them at runtime (without reboot) so don't worry about it at compile-time.
My understanding was that the "clever" schedulers (CFQ and deadline) are only really helpful on traditional "spinning disc" devices which don't have a RAID controller.