devel Digest, Vol 75, Issue 41
Salil Sirotia
salil.sirotia at gmail.com
Fri Feb 23 17:19:14 UTC 2018
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-request at rtems.org> wrote:
> [image: Boxbe] <https://www.boxbe.com/overview> This message is eligible
> for Automatic Cleanup! (devel-request at 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 at 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-request at rtems.org
>
> You can reach the person managing the list at
> devel-owner at 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.mauderer at embedded-brains.de>
> To: devel at rtems.org
> Subject: Re: GSOC 2018
> Message-ID: <8257435e-3cba-80df-1f42-817959fc49a6 at 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.mauderer at 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 <joel at rtems.org>
> To: Sebastian Huber <sebastian.huber at embedded-brains.de>
> Cc: devel <devel at 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.huber at embedded-brains.de> wrote:
>
> > ----- Am 22. Feb 2018 um 6:06 schrieb Chris Johns chrisj at 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 <chrisj at rtems.org>
> To: Sebastian Huber <sebastian.huber at embedded-brains.de>, joel
> <joel at rtems.org>
> Cc: devel <devel at rtems.org>
> Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support
> Message-ID: <4b0ada16-f114-1dab-1372-b5fb08e40421 at 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 <chrisj at rtems.org>
> To: devel at rtems.org
> Subject: [PATCH] sb: Covert any unicode keys to strings
> Message-ID: <20180223015951.68196-1-chrisj at 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 <chrisj at rtems.org>
> To: devel at rtems.org
> Subject: [PATCH] sb: Convert any unicode keys to strings
> Message-ID: <20180223020418.68287-1-chrisj at 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.huber at embedded-brains.de>
> To: Chris Johns <chrisj at rtems.org>
> Cc: devel <devel at rtems.org>
> Subject: Re: [PATCH v3 2/3] Add ARM Paravirtualization support
> Message-ID:
> <411038642.36489.1519354727816.JavaMail.zimbra at embedded-brains.de>
> Content-Type: text/plain; charset=utf-8
>
> ----- Am 23. Feb 2018 um 2:32 schrieb Chris Johns chrisj at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
> ------------------------------
>
> End of devel Digest, Vol 75, Issue 41
> *************************************
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180223/84608dcf/attachment-0001.html>
More information about the devel
mailing list