Re: Schedule() call in driver context.

Hi Joel, > You need to be clear with yourself on the meaning and the > types/differences of different contexts first, because its really > confusing when you say "kernel context (not interrupt)". Could you, please be a little more specific about what is confusing? As this is learning ground it w

Re: Schedule() call in driver context.

Hi Greg, Joel, > You're missing a tier of complexity and I'm afraid I don't know the... Agreed 100% :-) My intent was not to discuss the whole linux driver topic but to understand the subtleties of using "schedule()" in linux drivers. This point of view I have

Re: Schedule() call in driver context.

Hi Greg, I'm relatively new to this stuff but I think I will make some bold statements: > With linux today, is there a specific process context (ie. kernel > thread) associated with executing functions triggered by timers firing > off? No, a timer being fired wouldn't be associated with any sing

Re: Schedule() call in driver context.

> My understanding is the kernel uses interrupts to count the time and to > trigger timer routines - but these routine are executed in the context they > were registered. A timer created by a process executes in process > context. A driver registered timer executes in kernel context (not interrupt)

Re: Schedule() call in driver context.

On Tue, Feb 23, 2010 at 2:09 PM, Joel Fernandes wrote: > Hi Greg, > >> Instead there is an intermediary context that I don't think you've >> taken into account. >> >> I believe timers are also invoked in this intermediary context.  ie. >> When a timer invokes a function you can't trust the process

Re: Schedule() call in driver context.

> Like for example when a write() happens, this doesn't have to > necessarily go all the way till the disk immediately, instead its Ofcourse, unless the file is opened in O_DIRECT mode -Joel -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecar...@nl.linux.org

Re: Schedule() call in driver context.

Hi Greg, > Instead there is an intermediary context that I don't think you've > taken into account. > > I believe timers are also invoked in this intermediary context.  ie. > When a timer invokes a function you can't trust the process / task > structures to relate to your original userspace app.

Re: Schedule() call in driver context.

text during the driver initialization. There is no interrupt at > all. The > driver looks identical with the previous with the exception of the > interrupt/poll > handler. > > I was thinking at this case when I said you use timers to wait for the device > events. In fact

Re: Schedule() call in driver context.

at this case when I said you use timers to wait for the device events. In fact is you use timers to poll for device events. And, as I just learned you use "schedule()" to wait for kernel resources. Hope you agree with my approach. Cheers, Stephan. -- To unsubscribe from this list: send

Re: Schedule() call in driver context.

> My understanding is in a driver: > - use "schedule()" when waiting for kernel services. > - use timers when waiting for the device. Hi Stephan, You got it all right except the fact that you cannot use a timer because timers execute in interrupt context, not process context

Re: Schedule() call in driver context.

uncommon to have access to those restricted via a > semaphore or mutex. If you attempt to get a semaphore or mutex and it > fails the underlying call may very well call schedule for you. ... > If your driver can't ignore the hardware for a relatively long period > of time then &quo

Re: Schedule() call in driver context.

locks, timers, ... are taken > care by the kernel without any action of your side. Basically agreed, but for clarity: control structures are very common in drivers. ie. struct hardware_control_metadata { } It is not at all uncommon to have access to those restricted via a semaphore or mutex

Re: Schedule() call in driver context.

s, the driver is in an intended endless loop and wants to let the others to get some CPU. For this purpose(driver/device) I do not see any way to specify some wait-condition when calling "schedule()". Maybe I miss the point.. From what I see in the actual driver code I feel like the

Re: Schedule() call in driver context.

On Sat, Feb 20, 2010 at 2:01 AM, Joel Fernandes wrote: >> In fact the "kernel" is not interrupt-able in linux as I recall.  Thus >> a misbehaving driver that enters an infinite loop will hang the whole >> machine. > ... >> Another way to ask your question is "Why isn't the linux kernel itself >> t

Re: Schedule() call in driver context.

Hi Greg, Thanks for your message. You're right that fewer kernels have this, I thought that since CONFIG_PREEMPT documentation says its for low latency desktops (so that processes don't wait and the UI is more responsive), most desktop distros would have it enabled. But even on my Ubuntu 9.10 ker

Re: Schedule() call in driver context.

me? I mean instead calling > "schedule()" just > setup and start a timer which will trigger the same driver function until the > device > service is completed. You usually don't want to return once you need the resource, so I don't think a timer would work, but m

Re: Schedule() call in driver context.

>> Why would a linux driver call "schedule()" ? Thanks to all for your kind replies. If I summarize what I learned: <> >From what I know (please correct me if I'm wrong): 1. A driver executes in kernel context. An infinite loop will hang the system. 2. The dri

Re: Schedule() call in driver context.

Hi Stephan... Just sharing my humble thoughts... On Fri, Feb 19, 2010 at 4:39 AM, StephanT wrote: > Hello all, > > Why would a linux driver call "schedule()" ? Basically, to relinquish a certain kernel code path and to switch to the other one (be it user mode or kernel mod

Re: Schedule() call in driver context.

> In fact the "kernel" is not interrupt-able in linux as I recall.  Thus > a misbehaving driver that enters an infinite loop will hang the whole > machine. ... > Another way to ask your question is "Why isn't the linux kernel itself > timesliced?" AFAIK, What you're talking about is a kernel compi

Re: Schedule() call in driver context.

Yeah, schedule() (and __sched prefixed) function call needed when we are waiting for some events. It would de wasteful to lose CPU cycles while checking condition what we are waiting for. So, instead we can just to tell the kernel to switch to another task, and wake up our task when waiting

Re: Schedule() call in driver context.

On Thu, Feb 18, 2010 at 4:39 PM, StephanT wrote: > Hello all, > > Why would a linux driver call "schedule()" ? > > The LDD proposes this method to fight systems hangs caused by an infinite > loop in the driver. In this > case the "schedule()" call woul

Re: schedule

Hi, On Fri, 2010-02-19 at 11:42 -0500, sri ram vemulpali wrote: > Hi all, > > > Can anyone explain what is struct rcu_data and what does it > store. I suggest you read up on RCU (Read-copy update). You can find plenty of info on LWN: What is RCU, Fundamentally? - http://lwn.net/Articles/2

schedule

Hi all, Can anyone explain what is struct rcu_data and what does it store. /* 92 * Note a quiescent state. Because we do not need to know 93 * how many quiescent

Schedule() call in driver context.

Hello all, Why would a linux driver call "schedule()" ? The LDD proposes this method to fight systems hangs caused by an infinite loop in the driver. In this case the "schedule()" call would be a workaround. I think better fix the infinite loop and abstain to call schedul

Re: How to come a process slept after schedule() call.

e_t muk_write(struct file *filp, char const *buff, size_t count, > loff_t *f_pos) > { >prepare_to_wait(&muk_wr_wait, &my_wait, TASK_INTERRUPTIBLE); >schedule(); >finish_wait(&muk_wr_wait, &my_wait); > } > > and the read

How to come a process slept after schedule() call.

ount, loff_t *f_pos) { prepare_to_wait(&muk_wr_wait, &my_wait, TASK_INTERRUPTIBLE); schedule(); finish_wait(&muk_wr_wait, &my_wait); } and the read method is as follows: ssize_t muk_read(struct file *filp, char *buff, size_t count, loff_t *f_p