Re: Concurrency Kit and Epoch Based Reclamation
On 05/09/18 08:54, Chris Johns wrote: On 5/9/18 3:08 pm, Sebastian Huber wrote: On 05/09/18 01:38, Chris Johns wrote: On 5/9/18 2:40 am, Sebastian Huber wrote: The CK includes two additional licenses: https://github.com/concurrencykit/ck/blob/master/LICENSE I cannot see this file in the FreeBSD import. How does FreeBSD handle this? I guess they rely on per file license headers: https://github.com/freebsd/freebsd/blob/master/sys/contrib/ck/src/ck_hp.c The IBM code is under the Apache License, Version 2.0. I do not know how this license works as used here. The license states a copy needs to be supplied. Where is it stated that a copy needs to be supplied? I only see this "You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0";. Section 4.a of the license. The file in CK has the "applying the license" template as described in the license's appendix. There is also this link https://www.apache.org/legal/resolved.html#required-third-party-notices and while it deals with Apache releases it seems to have a clear intent. The 4.a is "You must give any other recipients of the Work or Derivative Works a copy of this License; and". This is probably fulfilled with the URL to http://www.apache.org/licenses/LICENSE-2.0 If not, then FreeBSD has an issue here. There are other parts of that license I find confusing when applied here, eg 5. As I stated before I am not sure how it works when used here with both licenses. If it is fine for FreeBSD, then it is fine for me. -- 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
Synchronization Problem on MPCI/shmdr on 2 Cores
Hi Joel, I ported RTEMS 4.11 to TI C6678 DSP. To enable multicore communication, I leveraged shared memory template provided in shmdr directory. When I tested it on 2 cores, there was a problem I currently cannot solve. Say, core 0 creates a *GLOBAL* message queue. Core 1 is the sender and core 0 the receiver. Everything goes well: core 0 receives a message instantly after core 1 sends one. However, when I switch their roles, things are beyond expectation: core 1 does not receive any until core 0 finishes its sending. The worst case is that if core 0 keeps on sending messages, core 1 will stay blocked and gets starved, which impacts its real-time requirements badly. I think that's because core 0 takes the preemptive opportunities to always manipulate global objects created on itself. For a stopgap, I had to rely on manually (hard-coded) explicit delay to meet the anticipation (ABABAB pattern between two nodes). But that is brittle since the latency of cache access and shared memory access may vary on different boards. Was I porting it wrong? Or is there already a solution to this? Thanks, Maxul ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-bsp-builder .ini file syntax question (for epiphany)
On Mon, Sep 3, 2018 at 7:12 PM Chris Johns wrote: > On 20/7/18 1:55 am, Joel Sherrill wrote: > > Epiphany can't build any network services. The GCC gives > > an Internal Compiler Error. On top of that, I recall the > > epiphany is too small to really run one of our network > > stacks anyway. > > > > in rtems-bsps-ephipany.ini, I wanted to change > > > > exclude = smp > > > > to > > > > exclude = smp, network > > > > But that seems to be illegal. > > > > What you have is right, there seems to be a bug in the build job processing > which I have fixed and will push to master. > > > I can mark it as exclude for the single BSP but it seems best to > > exclude two things on this architecture and I am unsure of the > > syntax (or if it is supported). > > It is supported. > > > Advice appreciated. > > The builds are defined here: > > https://git.rtems.org/rtems-tools/tree/tester/rtems/rtems-bsps.ini#n120 > > A build is a single word like 'smp', 'debug' and 'network'. The inverse of > the > build has 'no' prefixed with a '-' delimiter. This allows excluding to > work by > specifying the build, ie 'network', and any instance of the build in the > build > string is removed including 'no-network'. For example adding 'smp, > network' to > the 'ephipany' exclude list removes the following from the build list: > > 'network' > 'network-debug' > 'no-network' > 'smp-network' > 'smp-network-debug' > 'smp' > 'smp-debug' > 'smp-network' > 'smp-network-debug' > > A build maps to a configuration and these are defined in the '[config]' > section. > The build section show how the config section entries are referenced and > those > entries are autoconf configure options. > > You can check what happens with: > > $ ./tester/rtems-bsp-builder --dry-run \ >--rtems /opt/work/chris/rtems/kernel/rtems.git/ \ >--arch epiphany > https://lists.rtems.org/pipermail/build/2018-September/000997.html still has epiphany failures. Not sure what else is going on. Do you see the pattern? Thanks for fixing some of the odd failures. --joel > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RISC-V Update (3)
Hello, I am now done with my work to add SMP support to the RISC-V port. The RISC-V port is on par with the ARM, PowerPC and SPARC ports. A big thanks to Hesham for the ground work from my side. In the driver area there is a lot to do. The device tree support in RTEMS is quite poor and more or less a collection of hacks. For complex drivers (USB, PCI, Ethernet, etc.) we should work together with FreeBSD and use the libbsd. -- 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
