Hi all I am more intrested in high level programming projects.Currently I am doing a project on wireless sensor networks in python. So please suggest me some Open project matching with my skills
Thanks & regards, Salil Sirotia, Mtech,CSE-IS(Final Year), IIT(ISM),Dhanbad On Fri, Feb 23, 2018 at 8:27 AM, <devel-requ...@rtems.org> wrote: > [image: Boxbe] <https://www.boxbe.com/overview> This message is eligible > for Automatic Cleanup! (devel-requ...@rtems.org) Add cleanup rule > <https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DrgGJJzJx4Ue6j1tOq2VfMbPkpEIhsVMN%252BcIkqFRPOSY%253D%26token%3D0Ms05lrhnX4ZVx2f3yzg5nd3QNBUKqRtQH6IDgYjO%252BFF731etfRAta05zTEJJgQqLOaCDSZ0zbdJR1jaE0E2hFi1NWVnSEQkaverFiCvT717VPdQn%252BDnuvitdr%252F26IWDcGKKKelZkkVu6fpwVk8A0A%253D%253D&tc_serial=36942243920&tc_rand=1497184358&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001> > | More info > <http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=36942243920&tc_rand=1497184358&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001> > > Send devel mailing list submissions to > devel@rtems.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.rtems.org/mailman/listinfo/devel > or, via email, send a message with subject or body 'help' to > devel-requ...@rtems.org > > You can reach the person managing the list at > devel-ow...@rtems.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > > Today's Topics: > > 1. Re: GSOC 2018 (Christian Mauderer) > 2. Re: [PATCH 0/3] v3 - Paravirtualization Patch Series > (Joel Sherrill) > 3. Re: [PATCH v3 2/3] Add ARM Paravirtualization support > (Chris Johns) > 4. [PATCH] sb: Covert any unicode keys to strings (Chris Johns) > 5. [PATCH] sb: Convert any unicode keys to strings (Chris Johns) > 6. Re: [PATCH v3 2/3] Add ARM Paravirtualization support > (Sebastian Huber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Feb 2018 15:48:52 +0100 > From: Christian Mauderer <christian.maude...@embedded-brains.de> > To: devel@rtems.org > Subject: Re: GSOC 2018 > Message-ID: <8257435e-3cba-80df-1f42-817959fc4...@embedded-brains.de> > Content-Type: text/plain; charset=utf-8 > > Am 22.02.2018 um 03:35 schrieb Salil Sirotia: > > Hi all, > > > > My name is Salil Sirotia and I'd like to be a part of RTEMS project for > GSoC > > 2018. > > > > As of now, I have gone through 'Getting Started documentation' > > available on the?devel.rteme.org <http://devel.rteme.org/>?and have > > managed to set up a working environment > > for SPARC/ERC32.The wiki prospective students need to provide a proof > > of setting up environemt,? i've sent a snapshot with the modefied Hello > > World Test program after I ran it with ' sparc-rtems5-gdb ' as > > shown on the wiki page. Please Do let me know if I need to provide > > anything else . > > > > I have modified the hello world Sample application and Now I want to > > learn more things like Open Projects in RTEMS? Organization. > > Would you like to suggest me some Open Projects that match my skills? > > Any suggestion would be greatly appreciated. > > > > I would love to work on any open projects. > > My skills sets are :- > > C,C++ > > Begineer in Python,Java > > > > > > Hello Salil, > > first of all: Welcome to RTEMS. > > It really depends on what you would like to do. For some open projects, > you can have a look at the OpenProjects page in the wiki: > > https://devel.rtems.org/wiki/Developer/OpenProjects > > If you see something that interests you, just start to discuss it on the > mailing list. If you have some ideas of your own you can discuss them too. > > If you can't decide, it would be useful if you could tell us something > more about your interests and experience. Are you interested more in > high-level programming or something as close to hardware as possible? > Did your already use some embedded boards like Beagle or Raspberry? > > Kind regards > > Christian Mauderer > > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG. > > > ------------------------------ > > Message: 2 > Date: Thu, 22 Feb 2018 10:57:46 -0600 > From: Joel Sherrill <j...@rtems.org> > To: Sebastian Huber <sebastian.hu...@embedded-brains.de> > Cc: devel <devel@rtems.org> > Subject: Re: [PATCH 0/3] v3 - Paravirtualization Patch Series > Message-ID: > <CAF9ehCUuyEj+Tqct1w3x29+2Zgd99Q=aXzYqj6i0_MVZ-6XQHQ@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Feb 22, 2018 at 5:42 AM, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > > > ----- Am 22. Feb 2018 um 6:06 schrieb Chris Johns chr...@rtems.org: > > > > > On 22/02/2018 13:37, Sebastian Huber wrote: > > >>> > > >>> Architecture-specific names should use an ARCH_ or _Arch prefix and > > not CPU_ARCH > > >>> or _CPU_Arch. > > >>> > > >>> This > > >>> > > >>> CPU_DISABLE_INLINE_ISR_DISABLE_ENABLE > > >>> > > >>> is an architecture-specific implementation detail which doesn't > > propagate to > > >>> generic files, e.g. rtems/score/isrlevel.h, so it should not be > > introduced from > > >>> my point of view. > > > > OK. I can add an architecture to the constant but my hope was that > isrlevel.h would eventually be where the cut off to the paravirtualized > ISR disable/enable methods would be made. > > > > >>> I don't think it is worth to add a rtems/score/paravirt.h for each > > architecture. > > >>> The changes introduced by RTEMS_PARAVIRT are too small to justify > > this. I am > > >>> also not sure if you can encapsulate this in one header in all cases. > > >> > > >> Please don't ignore this. > > >> > > > > > > I felt spreading the RTEMS_PARAVIRT across the code was hiding the > > reason in > > > some cases. When I reviewed the v2 patches I felt changes in a specific > > area > > > needed more information to aid long term maintenance. For example look > > at the > > > ARM thread id register. It is clear what is happening and if that > change > > flows > > > out to other parts of the system it is clear what is happening if there > > is a > > > dependence on that register. > > > > Yes, this is all right, but do we really need a special header file for > > this? We can do this in one area of cpu.h or cpuimpl.h. > > > > It might be able to go near the top of cpu.h. But the inclusion of > paravirt.h is already > wrapped in a conditional so it isn't impacting normal compiles. > > Given that this file exists to specifically map an RTEMS configuration onto > architectural tweaks and document them, I still think they should be in > their > own file. Putting it at the top of cpu.h is likely technically feasible but > doesn't > achieve the goal of having a clear place to document paravirtualization > tweaks, etc. > > > > > > One long term goal is to reduce the implementation details visible via > > <rtems.h> and move more and more stuff into cpuimpl.h. This paravirt.h > is a > > step back under this point of view. > > > > It was actually hiding the reason for the conditional in all cases. > > Chris' suggestion was because none of this can be tested without special > setups which are not generally available. Plus it is completely > undocumented > what the host restrictions and requirements were that led to the > conditionals > being put in place. > > This header file is primarily to document (and do a good job of it) the > paravirtualization changes. Your thread id response is a perfect example. > The need to compile with that option should have been documented. As > the code is today, the definition of that register is only implied by > a GCC architectural revision. The register is indeed present in our > paravirtualized environment but we can't set it because it can't > be set in user mode. You already solved this problem and could > have even provided the helper routine for paravirtualized environments. > > Scattering around a bunch of undocumented tweaks without a > way to document them is bad. Especially when only the person > who did the paravirtualization adapter for a specific host knows the > details. > > I agreed with Chris that in-code documentation was the answer > and providing a nice container for it was the answer. > > Having paravirt.h could have the configure process give you an > error if the architecture doesn't have it -- which implies it doesn't > support it. > > --joel > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.rtems.org/pipermail/devel/attachments/ > 20180222/343c4d48/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Fri, 23 Feb 2018 12:32:00 +1100 > From: Chris Johns <chr...@rtems.org> > To: Sebastian Huber <sebastian.hu...@embedded-brains.de>, joel > <j...@rtems.org> > Cc: devel <devel@rtems.org> > Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support > Message-ID: <4b0ada16-f114-1dab-1372-b5fb08e40...@rtems.org> > Content-Type: text/plain; charset=utf-8 > > On 22/02/2018 22:39, Sebastian Huber wrote: > > For the XtratuM support on ARMv7-R I simply built the tools via the RSB > and added "-mtp=soft" to the C/C++ flags. I also used "-mtp=soft" for the > BSP, this instructs GCC to use calls to __aeabi_read_tp(). > > I had no idea this was the case. > > On ARM or to be more specific on ARM SMP builds the thread ID will have to > be > set to the thread TCB on ARM SMP machines by the context switcher. It is > needed > to support libdebugger on SMP for stepping to work. > > Chris > > > ------------------------------ > > Message: 4 > Date: Fri, 23 Feb 2018 12:59:51 +1100 > From: Chris Johns <chr...@rtems.org> > To: devel@rtems.org > Subject: [PATCH] sb: Covert any unicode keys to strings > Message-ID: <20180223015951.68196-1-chr...@rtems.org> > > Closes #3312 > --- > source-builder/sb/macros.py | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/source-builder/sb/macros.py b/source-builder/sb/macros.py > index 28a52b2..cf25783 100644 > --- a/source-builder/sb/macros.py > +++ b/source-builder/sb/macros.py > @@ -150,7 +150,7 @@ class macros: > def __setitem__(self, key, value): > key = self._unicode_to_str(key) > if type(key) is not str: > - raise TypeError('bad key type (want str): %s' % (type(key))) > + raise TypeError('bad key type (want str): %s (%s)' % > (type(key), key)) > if type(value) is not tuple: > value = self._unicode_to_str(value) > if type(value) is str: > @@ -396,6 +396,7 @@ class macros: > (path.host(self.expand(name)))) > > def get(self, key, globals = True, maps = None): > + key = self._unicode_to_str(key) > if type(key) is not str: > raise TypeError('bad key type: %s' % (type(key))) > key = self.key_filter(key) > @@ -435,11 +436,10 @@ class macros: > return self.get_attribute(key) == 'override' > > def define(self, key, value = '1'): > - if type(key) is not str: > - raise TypeError('bad key type: %s' % (type(key))) > self.__setitem__(key, ('none', 'none', value)) > > def undefine(self, key): > + key = self._unicode_to_str(key) > if type(key) is not str: > raise TypeError('bad key type: %s' % (type(key))) > key = self.key_filter(key) > -- > 2.14.1 > > > > ------------------------------ > > Message: 5 > Date: Fri, 23 Feb 2018 13:04:18 +1100 > From: Chris Johns <chr...@rtems.org> > To: devel@rtems.org > Subject: [PATCH] sb: Convert any unicode keys to strings > Message-ID: <20180223020418.68287-1-chr...@rtems.org> > > Closes #3313 > --- > source-builder/sb/macros.py | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/source-builder/sb/macros.py b/source-builder/sb/macros.py > index 28a52b2..cf25783 100644 > --- a/source-builder/sb/macros.py > +++ b/source-builder/sb/macros.py > @@ -150,7 +150,7 @@ class macros: > def __setitem__(self, key, value): > key = self._unicode_to_str(key) > if type(key) is not str: > - raise TypeError('bad key type (want str): %s' % (type(key))) > + raise TypeError('bad key type (want str): %s (%s)' % > (type(key), key)) > if type(value) is not tuple: > value = self._unicode_to_str(value) > if type(value) is str: > @@ -396,6 +396,7 @@ class macros: > (path.host(self.expand(name)))) > > def get(self, key, globals = True, maps = None): > + key = self._unicode_to_str(key) > if type(key) is not str: > raise TypeError('bad key type: %s' % (type(key))) > key = self.key_filter(key) > @@ -435,11 +436,10 @@ class macros: > return self.get_attribute(key) == 'override' > > def define(self, key, value = '1'): > - if type(key) is not str: > - raise TypeError('bad key type: %s' % (type(key))) > self.__setitem__(key, ('none', 'none', value)) > > def undefine(self, key): > + key = self._unicode_to_str(key) > if type(key) is not str: > raise TypeError('bad key type: %s' % (type(key))) > key = self.key_filter(key) > -- > 2.14.1 > > > > ------------------------------ > > Message: 6 > Date: Fri, 23 Feb 2018 03:58:47 +0100 (CET) > From: Sebastian Huber <sebastian.hu...@embedded-brains.de> > To: Chris Johns <chr...@rtems.org> > Cc: devel <devel@rtems.org> > Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support > Message-ID: > <411038642.36489.1519354727816.javamail.zim...@embedded-brains.de> > Content-Type: text/plain; charset=utf-8 > > ----- Am 23. Feb 2018 um 2:32 schrieb Chris Johns chr...@rtems.org: > > > On 22/02/2018 22:39, Sebastian Huber wrote: > >> For the XtratuM support on ARMv7-R I simply built the tools via the RSB > and > >> added "-mtp=soft" to the C/C++ flags. I also used "-mtp=soft" for the > BSP, this > >> instructs GCC to use calls to __aeabi_read_tp(). > > > > I had no idea this was the case. > > This is a workaround for an XtratuM shortcoming. A proper hypervisor would > support a hypercall to set the TPIDRURO. > > > > > On ARM or to be more specific on ARM SMP builds the thread ID will have > to be > > set to the thread TCB on ARM SMP machines by the context switcher. It is > needed > > to support libdebugger on SMP for stepping to work. > > This is fine. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > > ------------------------------ > > End of devel Digest, Vol 75, Issue 41 > ************************************* > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
