Hi ,

Yes ,both rtl_delay in RT and udelay in Linux ultimately boil down to
__delay(),but the rtl_delay will run smoothly.
I am greatly confused by this. I had never realized there is a so fantastic
thing lies behind it.

What I still cannot understand is why Linux cannot advance when a RT task
execute udelay().

When the udelay is running , Interrupts can be triggered and nothing prevent
it. So Interrupt can go on. And anything else in Linux will not able to run
because of the schedule mechanism of RTL.
And I thought that code in linux  will be usable if it is reentrant?

Where am I wrong ? I am a student, and I will not be shamed of making
mistake. Please point me out.

Thank you .


Dyd


>In V3 RTLinux we have "udelay" native.
>What is happens when you use the Linux udelay? Note it is a busy waiting
>loop, so  if you call the Linux udelay from a RT context, Linux will
>not advance.

>On Sat, Jul 08, 2000 at 03:26:18PM +0800, dyd wrote:
>> Hi all,
>>
>> I found udelay may cause dead in rtl , And Yodaiken said that udelay
cannot
>> be used in rtl context in a thread of Jun 18.(I paste the thread below.)
>>
>> But after examined the code of udelay I did not found any special
operation.
>> As far as I see, the code is nothing more than a busy loop, and it only
use
>> a piece of data in Linux ,the current_cpu_data.loops_per_sec.
>> Who can ponit out where the mistake is? thanks a lot.
>>
>> #define udelay(n) (__builtin_constant_p(n) ? \
>>  __const_udelay((n) * 0x10c6ul) : \
>>  __udelay(n))
>>
>> inline void __const_udelay(unsigned long xloops)
>> {
>>  int d0;
>>  __asm__("mull %0"
>>   :"=d" (xloops), "=&a" (d0)
>>   :"1" (xloops),"0" (current_cpu_data.loops_per_sec));
>>         __delay(xloops);
>> }
>>
>> void __udelay(unsigned long usecs)
>> {
>>  __const_udelay(usecs * 0x000010c6);  /* 2**32 / 1000000 */
>> }
>>
>> This is the thread I mentioned.
>> On Sat, Jun 17, 2000 at 11:52:57PM +0800, Zaimin Zhong wrote:
>> > Hi!
>> >
>> > Sorry to waste the bandwidth, but I could not link following functions
>> >
>> > check_region()
>> > request_region()
>> > udelay()
>>
>> These  are exported kernel functions and are linked in dynamically by
insmod
>> but
>> live in kernel space and cannot be statically linked.
>> (BTW: they cannot be used in RT threads or interrupt handlers).
>>
>> >
>> > statically into my RTL module. Which libary must be linked when above
>> > functions are called.
>> >
>>
>> dyd
>>
>>
>>
>>
>> -- [rtl] ---
>> To unsubscribe:
>> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
>> ---
>> For more information on Real-Time Linux see:
>> http://www.rtlinux.org/rtlinux/
>
>--
>---------------------------------------------------------
>Victor Yodaiken
>FSMLabs:  www.fsmlabs.com  www.rtlinux.com
>FSMLabs is a servicemark and a service of
>VJY Associates L.L.C, New Mexico.
>
>-- [rtl] ---
>To unsubscribe:
>echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
>echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
>---
>For more information on Real-Time Linux see:
>http://www.rtlinux.org/rtlinux/
>






-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Reply via email to