On 5/18/07, 陈涛 <eastage@xxxxxxxxxx> wrote:> Dear all:> As you both agree that an ISR cann't be asleep in an interrupt CONTEXT,> it remind me of another question as below.> Can a system timer tick ISR schedule user processes in nested interrupt CONTEXT?I do not think so. system tick ISR does not schedules directly anyprocess for that matter.Only thing it can and perhaps anyother processcan do is request the scheduler to schedule a process or itself bychanging the state.The moment scheduler sees it, it may run the process.
I think when hardware timer tick interrupt fires in non nested interrupt CONTEXT,> its related ISR will schedule user processes and also clear stack data(containing SS CS EFLAG IP,etc,in X86 system)> in kernel stack stored in when timer tick ISR fires.Apologies I am not able to understand what you are saying, sorry :-(
Thanks~psr> Does this mean the timer tick ISR sometimes cannot directly return to the process CONTEXT> which interrupted by the timer tick ISR?>> Hi, Phillip,>> I have said the gap between you and me is the definition of context.> In Robert's definition, *context* is used in a classification method> and really something in higher-level. And I used that term to explain> why ISR can not sleep.>> If you do not like the name, name it your way and substitute term> *context* in my previous mail with what you name. But I believe my> other explaination still hold, right?>> And again, if anyway I am forced to use your termnology system, I> would also agree your other point regarding hardware.>>> 2007/5/18, Phillip Susi <psusi@xxxxxxxxxx>:> > Dong Feng wrote:> > > OK. I think the gap between you and me is the definition of term> > > *context*. If you go to Linux Kernel Development, 2nd Edition (ISBN> > > 0-672-32720-1), Page 6, then you will read the following:> > >> > > .... in Linux, ... each processor is doing one of three things at any> > > given moment:> > >> > > 1. In kernel-space, in process context, ...> > > 2. In kernel-space, in interrupt context, not associated with a process,> > > ...> > > 3. In user-space ...> > >> > > This list is inclusive. ...> >> > Yep, I disagree with that use of the term, because it is misleading and> > caused your confusion. The context that the ISR executes in is not> > associated with a _known_ process is more correct.> >> > > Maybe you prefer other terminology system, but I do like the above> > > definition given by Robert Love. So maybe in your system *context*> > > mean something at hardware level and you say ISR is in process> > > context, but I think it is more like a logical level and agree with> > > Rovert's definition.> > >> > > And in hardware level, Robert's *context* definition also mean> > > something specific, that I started to be aware of. That is, *in the> > > same context* means a kernel-code is triggered by a user-space code.> > > *in different context* means a kernel-code is triggered by an external> > > interrupt source other than a user-space code.> >> > Right, and that becomes more clear when you say that the ISR's is> > executing in an indeterminate process context, rather than saying it> > does not have any context at all, or has its own special context.> >> > > Context has nothing to do with whether an ISR borrow any data> > > structure of a process, instead, its something logical or related to> > > causality.> >> > No, it has everything to do with the data structures of the process.> > When you are executing "in the same context" as you put it, as called> > from the user mode code, you know you are using the task structure of> > that process and so you can make use of that structure. For example,> > you can look at the current uid to decide if you should allow an> > operation to proceed. When you are in an ISR, there _is_ a task> > structure there, but you shouldn't use it because you don't know which> > task structure it is because you don't know which task you are> > interrupting. Thus if you look at the current uid in an ISR, you have> > no idea what you will see there and it will change from interrupt to> > interrupt, depending on which task gets interrupted.> >> >> >> -> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in> the body of a message to majordomo@xxxxxxxxxxxxxxx> More majordomo info at http://vger.kernel.org/majordomo-info.html> Please read the FAQ at http://www.linux-learn.org/faqs>>>>>> ******声明******> 本邮件及其附件所包含的信息均属深圳市同洲电子股份有限公司商业秘密，仅限于指定的个人或组织使用，未经许可，不得泄露给任何第三方。如果您不是本邮件的预期收件人，请立即将此错误告知本发件人，并迅速永久性删除本邮件及附件的所有原始件、复制件和输出件，请勿保存、复制、利用和泄露本邮件及附件的任何内容，以确保您无须为此承担法律责任。谢谢您的合作！> ******NOTICE******> This email and any files transmitted with it may contain legally PRIVILEGED and/or CONFIDENTIAL INFORMATION, and are intended solely for the personal use of the recipient(s) named above. Without prior consent, you should not disseminate this communication to any irrelevant party. If you have received this communication in error, please immediately notify this sender and permanently delete the original & duplicate copy, and any printout thereof. Any dissemination, distribution or copying of this communication is STRICTLY PROHIBITED. Thank you!>>>>
-- play the game��.n��������+%����w�j)p���{.n����z�ޖw�n'���q���b�������v��m�����Y�����
