Re: Regarding a beginner friendly bug
Hello Tanu Hari Dixit, On 31/01/17 19:15, Tanu Hari Dixit wrote: Hello all, Is there a beginner friendly bug that I can be assigned? I would like to get involved and learn more about RTEMS. these three bugs are close to being beginner friendly: https://devel.rtems.org/ticket/2375 https://devel.rtems.org/ticket/2353 https://devel.rtems.org/ticket/2550 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Mentors / Projects of Interest
Hello, I'm unable to change the content of "Description" field on Trac. I read https://devel.rtems.org/wiki/TracTickets and couldn't find any luck. I read a thread on Trac's mailing list (https://lists.gt.net/trac/users/46376). Perhaps, it has to do something with TICKET_EDIT_DESCRIPTION permissions. How do I go about doing this? What is it that I'm missing? Regards, Tanu Hari Dixit. On Wed, Feb 1, 2017 at 9:25 AM, Tanu Hari Dixit wrote: >> * You removed the "Introduction" section. Any reason or just an oversight? >> * The 'status' field is gone too. But, I think the status is not >> needed in the ticket format. > > I removed the "Introduction" section by mistake. I'll include it. > >> >> Did you face any difficulties in making the transition? It would be >> good to document your workflow on the Open Projects page. > > I wikiformatted the text myself. But it would have been better if I > had just copied the already formatted text that pops up when we try to > edit the project page > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP?action=edit). > No difficulties as such. I'll document the workflow on the open > projects page. > >> We should convert all of the open projects to tickets eventually. And >> then generate a report in the Open Projects page based on the tickets. >> I have done this for the BSP ones and found the following changes >> should be made in the workflow: > > Could you please direct me to the tickets you created? I couldn't find > them on Trac. > > >> I knew I had bought at least one so went to Amazon to see what we >> have here at OAR. >> >> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A >> >> Other folks in the community may have alternatives. It is a pretty generic >> piece of hardware. But there was that issue with the FTDI driver refusing >> to work with cloned FTDI chips. So I would bet there are some out there >> you don't want. > > I'll include the above hyperlink. > > Thanks, > Tanu Hari Dixit. > > On Wed, Feb 1, 2017 at 4:33 AM, Joel Sherrill wrote: >> >> >> On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom wrote: >>> >>> On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit >>> wrote: >>> > Hello, >>> > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of >>> > Gedare's advice for this open project >>> > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP). >>> Looks nice, a few minor things: >>> * You removed the "Introduction" section. Any reason or just an oversight? >>> * The 'status' field is gone too. But, I think the status is not >>> needed in the ticket format. >>> >>> Did you face any difficulties in making the transition? It would be >>> good to document your workflow on the Open Projects page. >>> >>> > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is >>> > probably broken. What should I replace it with? Please tell if some >>> See if you can find something appropriate on Google? >>> >> >> I knew I had bought at least one so went to Amazon to see what we >> have here at OAR. >> >> https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A >> >> Other folks in the community may have alternatives. It is a pretty generic >> piece of hardware. But there was that issue with the FTDI driver refusing >> to work with cloned FTDI chips. So I would bet there are some out there >> you don't want. >> >>> >>> > edit is needed and whether I should follow this pattern. Furthermore, >>> > please indicate whether this project is of interest. Also which other >>> > open projects should be converted to tickets? >>> > >>> We should convert all of the open projects to tickets eventually. And >>> then generate a report in the Open Projects page based on the tickets. >>> I have done this for the BSP ones and found the following changes >>> should be made in the workflow: >>> * Use only one keyword. I prefer "SoC" so it is generic to other >>> 'summer of code' style projects. >>> * Use the components field to further categorize. We have some obvious >>> ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'. >>> Others should be identified or else we can create new components if >>> necessary. I'd like to stick with the current subheadings for this >>> year's GSoC, but we can revise later. >>> >>> > Probably the community is interested in the idea to create simple >>> > examples or sanity tests for all RTEMS directives so that they can be >>> > included in the documentation (something that is user friendly). Also, >>> > there was a thread titled 'Desirable Application Stacks (Add-On >>> > Library Collections)' . Which ideas can be derived from there? >>> > >>> > Regards, >>> > Tanu Hari Dixit. >>> > >>> > On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill wrote: >>> >> >>> >> >>> >> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom wrote: >>> >>> >>> >>> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit >>> >>> >>> >>> wrote: >>> >>> > I'll be glad to d
Re: GSoC Mentors / Projects of Interest
> * You removed the "Introduction" section. Any reason or just an oversight? > * The 'status' field is gone too. But, I think the status is not > needed in the ticket format. I removed the "Introduction" section by mistake. I'll include it. > > Did you face any difficulties in making the transition? It would be > good to document your workflow on the Open Projects page. I wikiformatted the text myself. But it would have been better if I had just copied the already formatted text that pops up when we try to edit the project page (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP?action=edit). No difficulties as such. I'll document the workflow on the open projects page. > We should convert all of the open projects to tickets eventually. And > then generate a report in the Open Projects page based on the tickets. > I have done this for the BSP ones and found the following changes > should be made in the workflow: Could you please direct me to the tickets you created? I couldn't find them on Trac. > I knew I had bought at least one so went to Amazon to see what we > have here at OAR. > > https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A > > Other folks in the community may have alternatives. It is a pretty generic > piece of hardware. But there was that issue with the FTDI driver refusing > to work with cloned FTDI chips. So I would bet there are some out there > you don't want. I'll include the above hyperlink. Thanks, Tanu Hari Dixit. On Wed, Feb 1, 2017 at 4:33 AM, Joel Sherrill wrote: > > > On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom wrote: >> >> On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit >> wrote: >> > Hello, >> > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of >> > Gedare's advice for this open project >> > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP). >> Looks nice, a few minor things: >> * You removed the "Introduction" section. Any reason or just an oversight? >> * The 'status' field is gone too. But, I think the status is not >> needed in the ticket format. >> >> Did you face any difficulties in making the transition? It would be >> good to document your workflow on the Open Projects page. >> >> > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is >> > probably broken. What should I replace it with? Please tell if some >> See if you can find something appropriate on Google? >> > > I knew I had bought at least one so went to Amazon to see what we > have here at OAR. > > https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A > > Other folks in the community may have alternatives. It is a pretty generic > piece of hardware. But there was that issue with the FTDI driver refusing > to work with cloned FTDI chips. So I would bet there are some out there > you don't want. > >> >> > edit is needed and whether I should follow this pattern. Furthermore, >> > please indicate whether this project is of interest. Also which other >> > open projects should be converted to tickets? >> > >> We should convert all of the open projects to tickets eventually. And >> then generate a report in the Open Projects page based on the tickets. >> I have done this for the BSP ones and found the following changes >> should be made in the workflow: >> * Use only one keyword. I prefer "SoC" so it is generic to other >> 'summer of code' style projects. >> * Use the components field to further categorize. We have some obvious >> ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'. >> Others should be identified or else we can create new components if >> necessary. I'd like to stick with the current subheadings for this >> year's GSoC, but we can revise later. >> >> > Probably the community is interested in the idea to create simple >> > examples or sanity tests for all RTEMS directives so that they can be >> > included in the documentation (something that is user friendly). Also, >> > there was a thread titled 'Desirable Application Stacks (Add-On >> > Library Collections)' . Which ideas can be derived from there? >> > >> > Regards, >> > Tanu Hari Dixit. >> > >> > On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill wrote: >> >> >> >> >> >> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom wrote: >> >>> >> >>> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit >> >>> >> >>> wrote: >> >>> > I'll be glad to do it. Please guide me as to how to proceed. >> >>> > >> >>> We will need to import each existing Open Project description into a >> >>> new ticket. It would be best to start with one to "try it out". The >> >>> project title should be the Summary of the ticket, the text of the >> >>> project page should be converted into the Description of the ticket, >> >>> type should be Enhancement, Milestone "Indefinite", and put GSoC into >> >>> the keywords, and we might want to use some other keywords e.g. to >> >>> define the project type (e.g. one of: testing, ecosystem,
Re: Regarding a beginner friendly bug
Thank you. I'll look into it. Regards, Tanu Hari Dixit. On Tue, Jan 31, 2017 at 11:50 PM, Kuan Hsun Chen wrote: > Hi, > > You can search by yourself on this website: https://devel.rtems.org/query > After you fix a bug and test your revision comprehensively, you can send-out > the patch to this mailing list. > > Best, > Kuan-Hsun > > 2017-01-31 19:15 GMT+01:00 Tanu Hari Dixit : >> >> Hello all, >> Is there a beginner friendly bug that I can be assigned? I would like >> to get involved and learn more about RTEMS. >> Thank you. >> Regards, >> Tanu Hari Dixit >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > > -- > M.Sc. Kuan-Hsun Chen > > TU Dortmund > Department of Computer Science 12 > Design Automation of Embedded Systems > Otto-Hahn-Strasse 16, Room 102 > > 44227 Dortmund > Germany > > Phone: +49 231 755 6124 > Mail: kuan-hsun.c...@tu-dortmund.de ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Mentors / Projects of Interest
On Tue, Jan 31, 2017 at 12:54 PM, Gedare Bloom wrote: > On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit > wrote: > > Hello, > > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of > > Gedare's advice for this open project > > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP). > Looks nice, a few minor things: > * You removed the "Introduction" section. Any reason or just an oversight? > * The 'status' field is gone too. But, I think the status is not > needed in the ticket format. > > Did you face any difficulties in making the transition? It would be > good to document your workflow on the Open Projects page. > > > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is > > probably broken. What should I replace it with? Please tell if some > See if you can find something appropriate on Google? > > I knew I had bought at least one so went to Amazon to see what we have here at OAR. https://www.amazon.com/GearMo-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A Other folks in the community may have alternatives. It is a pretty generic piece of hardware. But there was that issue with the FTDI driver refusing to work with cloned FTDI chips. So I would bet there are some out there you don't want. > > edit is needed and whether I should follow this pattern. Furthermore, > > please indicate whether this project is of interest. Also which other > > open projects should be converted to tickets? > > > We should convert all of the open projects to tickets eventually. And > then generate a report in the Open Projects page based on the tickets. > I have done this for the BSP ones and found the following changes > should be made in the workflow: > * Use only one keyword. I prefer "SoC" so it is generic to other > 'summer of code' style projects. > * Use the components field to further categorize. We have some obvious > ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'. > Others should be identified or else we can create new components if > necessary. I'd like to stick with the current subheadings for this > year's GSoC, but we can revise later. > > > Probably the community is interested in the idea to create simple > > examples or sanity tests for all RTEMS directives so that they can be > > included in the documentation (something that is user friendly). Also, > > there was a thread titled 'Desirable Application Stacks (Add-On > > Library Collections)' . Which ideas can be derived from there? > > > > Regards, > > Tanu Hari Dixit. > > > > On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill wrote: > >> > >> > >> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom wrote: > >>> > >>> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit < > tokencol...@gmail.com> > >>> wrote: > >>> > I'll be glad to do it. Please guide me as to how to proceed. > >>> > > >>> We will need to import each existing Open Project description into a > >>> new ticket. It would be best to start with one to "try it out". The > >>> project title should be the Summary of the ticket, the text of the > >>> project page should be converted into the Description of the ticket, > >>> type should be Enhancement, Milestone "Indefinite", and put GSoC into > >>> the keywords, and we might want to use some other keywords e.g. to > >>> define the project type (e.g. one of: testing, ecosystem, kernel, > >>> statistics, BSP, API, libbsd, languages, libraries). The owner should > >>> be assigned to one of the mentors if indicated, with others in CC if > >>> any, or else set blank. > >>> > >> > >> I agree it would be nice to get all the Open Project ideas as tickets > and > >> off the Wiki. Some of the ideas are likely no longer interesting/valid > at > >> this point and could just be deleted. > >> > >> FWIW I also want to move some of the Wiki content into Sphinx documents. > >> I think being able to release them with RTEMS branches and use git > >> for revision control. > >> > >> --joel > >> > >>> > >>> > On Mon, Jan 30, 2017 at 9:38 PM, Gedare Bloom > wrote: > >>> >> > >>> >> Yes that would be much nicer. Maybe we can get potential GSoC > Students > >>> >> to do the work ;) > >>> >> > >>> >> On Mon, Jan 30, 2017 at 1:40 AM, Sebastian Huber > >>> >> wrote: > >>> >> > Maybe we should move all this open projects wiki stuff into > tickets > >>> >> > with > >>> >> > some sort of "GSoC" tag. > >>> >> > > >>> >> > -- > >>> >> > Sebastian Huber, embedded brains GmbH > >>> >> > > >>> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany > >>> >> > Phone : +49 89 189 47 41-16 > >>> >> > Fax : +49 89 189 47 41-09 > >>> >> > E-Mail : sebastian.hu...@embedded-brains.de > >>> >> > PGP : Public key available on request. > >>> >> > > >>> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des > EHUG. > >>> >> > > >>> >> ___ > >>> >> devel mailing list > >>> >> devel@rtems.org > >>> >> http://lists.rtems.org/mailman/listinfo/devel > >>> > > >>> >
Re: GSoC Mentors / Projects of Interest
On Tue, Jan 31, 2017 at 12:21 PM, Tanu Hari Dixit wrote: > Hello, > I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of > Gedare's advice for this open project > (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP). Looks nice, a few minor things: * You removed the "Introduction" section. Any reason or just an oversight? * The 'status' field is gone too. But, I think the status is not needed in the ticket format. Did you face any difficulties in making the transition? It would be good to document your workflow on the Open Projects page. > The link to buy USB-TTL FTDI Cable 3.3V on the open project page is > probably broken. What should I replace it with? Please tell if some See if you can find something appropriate on Google? > edit is needed and whether I should follow this pattern. Furthermore, > please indicate whether this project is of interest. Also which other > open projects should be converted to tickets? > We should convert all of the open projects to tickets eventually. And then generate a report in the Open Projects page based on the tickets. I have done this for the BSP ones and found the following changes should be made in the workflow: * Use only one keyword. I prefer "SoC" so it is generic to other 'summer of code' style projects. * Use the components field to further categorize. We have some obvious ones for the subheadings now, such as 'bsps', 'libbsd', 'testing'. Others should be identified or else we can create new components if necessary. I'd like to stick with the current subheadings for this year's GSoC, but we can revise later. > Probably the community is interested in the idea to create simple > examples or sanity tests for all RTEMS directives so that they can be > included in the documentation (something that is user friendly). Also, > there was a thread titled 'Desirable Application Stacks (Add-On > Library Collections)' . Which ideas can be derived from there? > > Regards, > Tanu Hari Dixit. > > On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill wrote: >> >> >> On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom wrote: >>> >>> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit >>> wrote: >>> > I'll be glad to do it. Please guide me as to how to proceed. >>> > >>> We will need to import each existing Open Project description into a >>> new ticket. It would be best to start with one to "try it out". The >>> project title should be the Summary of the ticket, the text of the >>> project page should be converted into the Description of the ticket, >>> type should be Enhancement, Milestone "Indefinite", and put GSoC into >>> the keywords, and we might want to use some other keywords e.g. to >>> define the project type (e.g. one of: testing, ecosystem, kernel, >>> statistics, BSP, API, libbsd, languages, libraries). The owner should >>> be assigned to one of the mentors if indicated, with others in CC if >>> any, or else set blank. >>> >> >> I agree it would be nice to get all the Open Project ideas as tickets and >> off the Wiki. Some of the ideas are likely no longer interesting/valid at >> this point and could just be deleted. >> >> FWIW I also want to move some of the Wiki content into Sphinx documents. >> I think being able to release them with RTEMS branches and use git >> for revision control. >> >> --joel >> >>> >>> > On Mon, Jan 30, 2017 at 9:38 PM, Gedare Bloom wrote: >>> >> >>> >> Yes that would be much nicer. Maybe we can get potential GSoC Students >>> >> to do the work ;) >>> >> >>> >> On Mon, Jan 30, 2017 at 1:40 AM, Sebastian Huber >>> >> wrote: >>> >> > Maybe we should move all this open projects wiki stuff into tickets >>> >> > with >>> >> > some sort of "GSoC" tag. >>> >> > >>> >> > -- >>> >> > Sebastian Huber, embedded brains GmbH >>> >> > >>> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >>> >> > Phone : +49 89 189 47 41-16 >>> >> > Fax : +49 89 189 47 41-09 >>> >> > E-Mail : sebastian.hu...@embedded-brains.de >>> >> > PGP : Public key available on request. >>> >> > >>> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> >> > >>> >> ___ >>> >> devel mailing list >>> >> devel@rtems.org >>> >> http://lists.rtems.org/mailman/listinfo/devel >>> > >>> > >>> ___ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Regarding a beginner friendly bug
Hi, You can search by yourself on this website: https://devel.rtems.org/query After you fix a bug and test your revision comprehensively, you can send-out the patch to this mailing list. Best, Kuan-Hsun 2017-01-31 19:15 GMT+01:00 Tanu Hari Dixit : > Hello all, > Is there a beginner friendly bug that I can be assigned? I would like > to get involved and learn more about RTEMS. > Thank you. > Regards, > Tanu Hari Dixit > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- M.Sc. Kuan-Hsun Chen TU Dortmund Department of Computer Science 12 Design Automation of Embedded Systems Otto-Hahn-Strasse 16, Room 102 44227 Dortmund Germany Phone: *+49 231 755 6124 <+49%20231%207556124>* Mail: kuan-hsun.c...@tu-dortmund.de ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Regarding a beginner friendly bug
Hello all, Is there a beginner friendly bug that I can be assigned? I would like to get involved and learn more about RTEMS. Thank you. Regards, Tanu Hari Dixit ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Mentors / Projects of Interest
Hello, I created (https://devel.rtems.org/ticket/2891#ticket) on the lines of Gedare's advice for this open project (https://devel.rtems.org/wiki/Developer/Projects/Open/ImproveBeagleBSP). The link to buy USB-TTL FTDI Cable 3.3V on the open project page is probably broken. What should I replace it with? Please tell if some edit is needed and whether I should follow this pattern. Furthermore, please indicate whether this project is of interest. Also which other open projects should be converted to tickets? Probably the community is interested in the idea to create simple examples or sanity tests for all RTEMS directives so that they can be included in the documentation (something that is user friendly). Also, there was a thread titled 'Desirable Application Stacks (Add-On Library Collections)' . Which ideas can be derived from there? Regards, Tanu Hari Dixit. On Tue, Jan 31, 2017 at 4:52 AM, Joel Sherrill wrote: > > > On Mon, Jan 30, 2017 at 5:13 PM, Gedare Bloom wrote: >> >> On Mon, Jan 30, 2017 at 12:25 PM, Tanu Hari Dixit >> wrote: >> > I'll be glad to do it. Please guide me as to how to proceed. >> > >> We will need to import each existing Open Project description into a >> new ticket. It would be best to start with one to "try it out". The >> project title should be the Summary of the ticket, the text of the >> project page should be converted into the Description of the ticket, >> type should be Enhancement, Milestone "Indefinite", and put GSoC into >> the keywords, and we might want to use some other keywords e.g. to >> define the project type (e.g. one of: testing, ecosystem, kernel, >> statistics, BSP, API, libbsd, languages, libraries). The owner should >> be assigned to one of the mentors if indicated, with others in CC if >> any, or else set blank. >> > > I agree it would be nice to get all the Open Project ideas as tickets and > off the Wiki. Some of the ideas are likely no longer interesting/valid at > this point and could just be deleted. > > FWIW I also want to move some of the Wiki content into Sphinx documents. > I think being able to release them with RTEMS branches and use git > for revision control. > > --joel > >> >> > On Mon, Jan 30, 2017 at 9:38 PM, Gedare Bloom wrote: >> >> >> >> Yes that would be much nicer. Maybe we can get potential GSoC Students >> >> to do the work ;) >> >> >> >> On Mon, Jan 30, 2017 at 1:40 AM, Sebastian Huber >> >> wrote: >> >> > Maybe we should move all this open projects wiki stuff into tickets >> >> > with >> >> > some sort of "GSoC" tag. >> >> > >> >> > -- >> >> > Sebastian Huber, embedded brains GmbH >> >> > >> >> > Address : Dornierstr. 4, D-82178 Puchheim, Germany >> >> > Phone : +49 89 189 47 41-16 >> >> > Fax : +49 89 189 47 41-09 >> >> > E-Mail : sebastian.hu...@embedded-brains.de >> >> > PGP : Public key available on request. >> >> > >> >> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >> > >> >> ___ >> >> devel mailing list >> >> devel@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel >> > >> > >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] c-user: Add Key concept locking protocols
Update #2412. Update #2556. --- c-user/key_concepts.rst | 116 +++ c-user/semaphore_manager.rst | 93 +++--- common/refs.bib | 16 ++ 3 files changed, 140 insertions(+), 85 deletions(-) diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst index 26cdaf9..bda8e79 100644 --- a/c-user/key_concepts.rst +++ b/c-user/key_concepts.rst @@ -239,6 +239,122 @@ synchronization, while the event manager primarily provides a high performance synchronization mechanism. The signal manager supports only asynchronous communication and is typically used for exception handling. +Locking Protocols += +.. index:: locking protocols + +RTEMS supports the four locking protocols + +* :ref:`PriorityCeiling`, + +* :ref:`PriorityInheritance`, + +* :ref:`MrsP`, and + +* :ref:`OMIP` + +for synchronization objects providing mutual-exclusion (mutex). The OMIP is +only available in SMP configurations and replaces the priority inheritance +protocol in this case. One aim of the locking protocols is to avoid priority +inversion. + +Since RTEMS 4.12, priority updates due to the locking protocols take place +immediately and are propagated recursively. The mutex owner and wait for mutex +relationships define a directed acyclic graph (DAG). The run-time of the mutex +obtain, release and timeout operations depend on the complexity of this +resource dependency graph. + +.. _PriorityInversion: + +Priority Inversion +-- +.. index:: priority inversion + +Priority inversion is a form of indefinite postponement which is common in +multitasking, pre-emptive executives with shared resources. Priority inversion +occurs when a high priority tasks requests access to shared resource which is +currently allocated to a low priority task. The high priority task must block +until the low priority task releases the resource. This problem is exacerbated +when the low priority task is prevented from executing by one or more medium +priority tasks. Because the low priority task is not executing, it cannot +complete its interaction with the resource and release that resource. The high +priority task is effectively prevented from executing by lower priority tasks. + +.. _PriorityCeiling: + +Immediate Ceiling Priority Protocol (ICPP) +-- +.. index:: priority ceiling protocol +.. index:: immediate ceiling priority protocol + +Each mutex using the Immediate Ceiling Priority Protocol (ICPP) has a ceiling +priority. The priority of the mutex owner is immediately raised to the ceiling +priority of the mutex. In case the thread owning the mutex releases the mutex, +then the normal priority of the thread is restored. This locking protocol is +beneficial for schedulability analysis, see also +:cite:`Burns:2001:RealTimeSystems`. + +This protocol avoids the possibility of changing the priority of the mutex +owner multiple times since the ceiling priority must be set to the one of +highest priority thread which will ever attempt to acquire that mutex. This +requires an overall knowledge of the application as a whole. The need to +identify the highest priority thread which will attempt to obtain a particular +mutex can be a difficult task in a large, complicated system. Although the +priority ceiling protocol is more efficient than the priority inheritance +protocol with respect to the maximum number of thread priority changes which +may occur while a thread owns a particular mutex, the priority inheritance +protocol is more forgiving in that it does not require this apriori +information. + +.. _PriorityInheritance: + +Priority Inheritance Protocol +- +.. index:: priority inheritance protocol + +The priority of the mutex owner is raised to the highest priority of all +threads that currently wait for ownership of this mutex :cite:`Sha:1990:PI`. +Since RTEMS 4.12, priority updates due to the priority inheritance protocol +take place immediately and are propagated recursively. + +.. _MrsP: + +Multiprocessor Resource Sharing Protocol (MrsP) +--- +.. index:: Multiprocessor Resource Sharing Protocol (MrsP) + +The Multiprocessor Resource Sharing Protocol (MrsP) is a generalization of the +priority ceiling protocol to clustered scheduling :cite:`Burns:2013:MrsP`. One +of the design goals of MrsP is to enable an effective schedulability analysis +using the sporadic task model. Each mutex using the MrsP has a ceiling +priority for each scheduler instance. The priority of the mutex owner is +immediately raised to the ceiling priority of the mutex defined for its home +scheduler instance. In case the thread owning the mutex releases the mutex, +then the normal priority of the thread is restored. Threads that wait for +mutex ownership are not blocked with respect to the scheduler and instead +perform a busy wait. The MrsP uses
[PATCH 1/2] c-user: Add key concept thread queues
Update #2556. --- c-user/glossary.rst | 12 +-- c-user/key_concepts.rst | 53 + 2 files changed, 63 insertions(+), 2 deletions(-) diff --git a/c-user/glossary.rst b/c-user/glossary.rst index c482f08..9c4df99 100644 --- a/c-user/glossary.rst +++ b/c-user/glossary.rst @@ -639,10 +639,15 @@ Glossary :dfn:`target` The system on which the application will ultimately execute. +.. _task: + :dfn:`task` A logically complete thread of execution. It consists normally of a set of -registers and a stack. The terms :dfn:`task` and :dfn:`thread` are synonym -in RTEMS. The scheduler assigns processors to a subset of the ready tasks. +registers and a stack. The scheduler assigns processors to a subset of the +ready tasks. The terms :dfn:`task` and :dfn:`thread` are synonym in RTEMS. +The term :dfn:`task` is used throughout the Classic API, however, +internally in the operating system implementation and the POSIX API the +term :dfn:`thread` is used. :dfn:`Task Control Block` A data structure associated with each task used by RTEMS to manage that @@ -662,6 +667,9 @@ Glossary :dfn:`TCB` An acronym for Task Control Block. +:dfn:`thread` +See :ref:`task `. + :dfn:`thread dispatch` The :dfn:`thread dispatch` transfers control of the processor from the currently executing thread to the heir thread of the processor. diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst index e5c8cfd..26cdaf9 100644 --- a/c-user/key_concepts.rst +++ b/c-user/key_concepts.rst @@ -239,6 +239,59 @@ synchronization, while the event manager primarily provides a high performance synchronization mechanism. The signal manager supports only asynchronous communication and is typically used for exception handling. +Thread Queues += +.. index:: thread queues + +In case more than one :ref:`thread ` may wait on a synchronization +object, e.g. a semaphore or a message queue, then the waiting threads are added +to a data structure called the thread queue. Thread queues are named task wait +queues in the Classic API. There are two thread queuing disciplines available +which define the order of the threads on a particular thread queue. Threads +can wait in FIFO or priority order. + +In uni-processor configurations, the priority queuing discipline just orders +the threads according to their current priority and in FIFO order in case of +equal priorities. However, in SMP configurations, the situation is a bit more +difficult due to the support for clustered scheduling. It makes no sense to +compare the priority values of two different scheduler instances. Thus, it is +impossible to simply use one plain priority queue for threads of different +clusters. Two levels of queues can be used as one way to solve the problem. +The top-level queue provides FIFO ordering and contains priority queues. Each +priority queue is associated with a scheduler instance and contains only +threads of this scheduler instance. Threads are enqueued in the priority +queues corresponding to their scheduler instances. To dequeue a thread, the +highest priority thread of the first priority queue is selected. Once this is +done, the first priority queue is appended to the top-level FIFO queue. This +guarantees fairness with respect to the scheduler instances. + +Such a two-level queue needs a considerable amount of memory if fast enqueue +and dequeue operations are desired. Providing this storage per thread queue +would waste a lot of memory in typical applications. Instead, each thread has +a queue attached which resides in a dedicated memory space independent of other +memory used for the thread (this approach was borrowed from FreeBSD). In case +a thread needs to block, there are two options + +* the object already has a queue, then the thread enqueues itself to this + already present queue and the queue of the thread is added to a list of free + queues for this object, or + +* otherwise, the queue of the thread is given to the object and the thread + enqueues itself to this queue. + +In case the thread is dequeued, there are two options + +* the thread is the last thread in the queue, then it removes this queue + from the object and reclaims it for its own purpose, or + +* otherwise, the thread removes one queue from the free list of the object + and reclaims it for its own purpose. + +Since there are usually more objects than threads, this actually reduces the +memory demands. In addition the objects only contain a pointer to the queue +structure. This helps to hide implementation details. Inter-cluster priority +queues are available since RTEMS 4.12. + Time .. index:: time -- 1.8.4.5 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
