Re: [PATCH] bootstrap: Use printf instead of echo -e for POSIX shells

2018-03-10 Thread Chris Johns
On 11/3/18 3:36 pm, Amaan Cheval wrote: > "echo -e" only tells the echo command to enable interpretation of > backslashes. The string there doesn't actually use any, so it can do > without the flag - if I changed this to printf, I couldn't think of a > reason not to change all the other "echo"

Re: [PATCH] bootstrap: Use printf instead of echo -e for POSIX shells

2018-03-10 Thread Amaan Cheval
"echo -e" only tells the echo command to enable interpretation of backslashes. The string there doesn't actually use any, so it can do without the flag - if I changed this to printf, I couldn't think of a reason not to change all the other "echo" instances to printf as well. If that's a welcome

Re: [PATCH] bootstrap: Use printf instead of echo -e for POSIX shells

2018-03-10 Thread Chris Johns
I know this has already been pushed but ... On 10/3/18 2:55 am, Amaan Cheval wrote: > On POSIX compliant shells, echo does not have the -e option. > This causes the "-e" to be echoed as well, causing potential buggy > build processes. > > Example shell session: > > -> % sh > $ echo -e "foo bar"

Re: Suggestions regarding GSoC project

2018-03-10 Thread Christian Mauderer
Am 10.03.2018 um 19:08 schrieb Udit agarwal: > Hi all, > > On Sat, Mar 10, 2018 at 5:07 PM, Christian Mauderer > wrote: > > Am 10.03.2018 um 02:14 schrieb Udit agarwal: > > Hi all, Hi Christian Mauderer, Hi Russel Haley, > > > > I

Re: Suggestions regarding GSoC project

2018-03-10 Thread Udit agarwal
Hi all, On Sat, Mar 10, 2018 at 5:07 PM, Christian Mauderer wrote: > Am 10.03.2018 um 02:14 schrieb Udit agarwal: > > Hi all, Hi Christian Mauderer, Hi Russel Haley, > > > > I need some reviews/suggestions from the community regarding the idea of > > Porting FreeBSD's SDIO

GSoC 2018 (x86_64, pc386, SMP improvements, rump kernels)

2018-03-10 Thread Amaan Cheval
Hi! I've introduced myself in the past, but just to reiterate; I'm a final year Bachelor's in Engineering student at Thakur College of Engineering, in Mumbai. I work part-time on an Intel x86 emulator, written primarily in C and JavaScript (that's right :P) - we also have a JIT compiler for

Re: [PATCH 1/3] i386/smp: Define unused CPU_Interrupt_frame to fix compiler error

2018-03-10 Thread Amaan Cheval
Context: https://lists.rtems.org/pipermail/devel/2018-March/020409.html I just realized that it may make more sense to use uint8_t and a CPU_INTERRUPT_FRAME_SIZE of 1 instead, if we _do_ want to leave it unused but defined. Another option I considered was simply setting a preprocessor flag to

[PATCH 2/3] i386/smp: Have ld use incremental build for appstart.o

2018-03-10 Thread Amaan Cheval
With HAS_SMP set, we have: libbsp_a_LIBADD += appstart.$(OBJEXT) When trying to build appstart.o, however, we link start.o with appcpustart.o through the linkcmds script, which leaves several symbols unresolved, and without the "-r" (or -i) flag, this throws undefined reference errors. This

[PATCH 1/3] i386/smp: Define unused CPU_Interrupt_frame to fix compiler error

2018-03-10 Thread Amaan Cheval
CPU_INTERRUPT_FRAME_SIZE needs to also be set to allow the RTEMS_STATIC_ASSERT in percpuasm.c to be fulfilled. Updates #3331 --- cpukit/score/cpu/i386/include/rtems/score/cpu.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git

[PATCH 0/3] Allow i386 to compile with --enable-smp

2018-03-10 Thread Amaan Cheval
As discussed in the mailing list a few days ago[1], i386 needed a few patches to get it to compile with the --enable-smp flag. The patches take care of the simple compile and link-time errors that show up with the flag. I'm unsure about the CPU_Interrupt_frame change - all other architectures

[PATCH 3/3] i386/smp: Export _CPU_SMP_Prepare_start_multitasking as a function

2018-03-10 Thread Amaan Cheval
When it's a macro, a function declaration causes a compiler error due to the macro being expanded. Partial log showing error: https://gist.github.com/AmaanC/ab3521141479aa6f61ea25f5d74ebb4d Closes #3331 --- c/src/lib/libbsp/i386/shared/smp/smp-imps.c | 5 +

Re: Suggestions regarding GSoC project

2018-03-10 Thread Christian Mauderer
Am 10.03.2018 um 02:14 schrieb Udit agarwal: > Hi all, Hi Christian Mauderer, Hi Russel Haley, > > I need some reviews/suggestions from the community regarding the idea of > Porting FreeBSD's SDIO driver to RTEMS via libbsd , building and testing > on Beaglebone Black BSP and then benchmarking it