Patch for "strict order mutex"

Joel Sherrill joel.sherrill at oarcorp.com
Fri Oct 19 10:55:41 CDT 2007


xi yang wrote:
> Hi joel,ray
>
> Sorry, that's my fault, I worked based a CVS version , and I don't
> know how to get
> that copy from CVS,so the patch is so big.
>
> I will get the current version and then changed the souce of it ,then
> diff with this
> current  version tomorrow.
>   

You can do a "cvs diff -u" in any checked out cvs tree and it
will be ONLY the changes you made since that code was checked
out.

The resulting diff may or may not apply cleanly to the CVS head.

You can do a "cvs update -Pd" on your checked out tree.  If there
are conflicts between your edits and any edits since your original
check out, cvs will flag them for you to fix. 


Most of your changes are probably in places that didn't change
so a diff from the old cvs check out will probably be updated
fine.
> Regards.
>
> 2007/10/19, Joel Sherrill <joel.sherrill at oarcorp.com>:
>   
>> Ray wrote:
>>     
>>>   Thanks for your work. But pls compress your patch file before send to the maillist.
>>>   And I believe that you did not make the right patch in the attachment. It is hard to merge a patch file of 81,000 lines. It is a better idea to make a diff base on a freeze version (e.g. version 4.7.1 or CVS snapshot 4.7.99.2) because CVS is a moving target. It has to keep in mind that the patch should only contain your changes.
>>>
>>>
>>>       
>> Diffing this type of code against CVS isn't a big deal.  Usually it is
>> actually easier
>> for me to merge a patch against CVS than an older released version.
>>
>> But this patch wasn't generated in a way to be easy to deal with.  It
>> appears
>> to be a diff -uNr of a modified old tarball versus a fresh CVS checkout.
>>
>> Merge your change into the fresh CVS and then do this from the top:
>>
>> cvs diff -uN
>>
>> If you added a file, there are techniques to deal with that so cvs will
>> think
>> you added it locally.  But for now, just send those separate from the
>> main diff.
>>
>> Always update your cvs tree before doing a diff for submission.
>>
>> It really is easier for me if you make a diff against the RTEMS version you
>> will merge into.  Most of the time this is against the CVS head.  Make your
>> diff's to that and keep your local cvs up to date with "cvs up -Pd"
>>
>> --joel
>>     
>>> ------------------
>>> Thanks & Best Regards!
>>> Ray
>>> 2007-10-19
>>>
>>> -------------------------------------------------------------
>>> From: xi yang
>>> Date: 2007-10-19 02:15:49
>>> To:   RTEMS Users; Joel Sherrill
>>> CC:
>>> Sub:  Patch for "strict order mutex"
>>>
>>>
>>>       
>>>> 1)What's strict order mutex ?
>>>>
>>>>  In rtems,when a task release a priority_inheritance or
>>>>  priority ceiling semaphore,the kernel detect whether
>>>>  this task holds priority_inheritance or priority
>>>>  ceiling semaphore, if not, set the priority of task
>>>>  back to real priority of task.
>>>>  This method  is right, but in theory, we would like
>>>>  to reset the priority after releasing the mutex if
>>>>  releasing it in LIFO order.Do it like this can decrease
>>>>  the blocking time of a higher priority task .
>>>>
>>>> 2)How to enable "strict order mutex " ?
>>>>
>>>>  When configuring the rtems , add
>>>>  ENABLE_STRICT_ORDER_MUTEX=1
>>>>  to your configure parameter.
>>>>
>>>> I add sp36 to test the function of "strict order mutex"
>>>> 3)About this test program
>>>>
>>>> T0,T1,S0,S1
>>>>
>>>> T0,priority 4
>>>> T1,priority 1
>>>>
>>>> S0,priority inheritance
>>>>  S1,priority ceiling,priority ceiling 2
>>>>
>>>> 1,T0 obtain S0 then obtain S1, priority of T0 should be improved to 2
>>>> 2,T0 try to release S0, but not in strict order, return error code
>>>> 3,T0 release S1,the priority of T0 back to 4
>>>> 4,T1 try to obtain S0
>>>> 5,T1 should be blocked and the priority of T0 should be improved to 1
>>>> 6,T0 release S0
>>>> 7,T1 obtain S0
>>>> 8,OVER.
>>>>
>>>> I test it under bochs , this patch is for rtems that check form CVS as
>>>> cvs -d :pserver:anoncvs at www.rtems.com:/usr1/CVS -z 9 co
>>>> -rrtems-4-8-branch  rtems
>>>>
>>>> Regards.
>>>>
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>
>>>>
>>>>         
>>>       
>>     




More information about the rtems-users mailing list