Re: libbsd include path issue
On 24/07/2017 00:20, Christian Mauderer wrote: > Am 23.07.2017 um 15:57 schrieb Gedare Bloom: >> On Sun, Jul 23, 2017 at 8:38 AM, Christian Mauderer >> wrote: >>> The problem here is that the opensslv.h is in the directory >>> freebsd/crypto/openssl/crypto. It seems that some makefile magic would >>> install it to openssl/opensslv.h for the normal non-libbsd case (most >>> likely the "link" rule in freebsd/crypto/openssl/crypto/Makefile). >>> >> ah, I see. Then I can't think of any better solution than to make a >> rule something like you did that will copy the header file into an >> appropriate location of the build tree. The other alternative would be >> to create a softlink include/openssl in the source tree, effectively >> doing what the freebsd makefile would do during a build. > > I have shortly thought about that too. I think I've seen some functions > in waf that might could create that softlink. But I had two problems > with that: > > 1. Like I said, I have seen some functions that _might_ could create a > link but I'm not sure what would be the best and correctest way. Any hints? Could a waf 'subst' target be made to work? https://github.com/waf-project/waf/tree/master/demos/subst > 2. I have no idea how well that would work on a Windows build host. I > know that at least msys2 doesn't support soft links out of the box. They > are replaced by a copy. Any experience regarding that? I would avoid a symlink. Either of these solutions are not great but I also cannot see another way without effecting the upstream. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd include path issue
Am 24.07.2017 um 08:59 schrieb Chris Johns: > On 24/07/2017 00:20, Christian Mauderer wrote: >> Am 23.07.2017 um 15:57 schrieb Gedare Bloom: >>> On Sun, Jul 23, 2017 at 8:38 AM, Christian Mauderer >>> wrote: The problem here is that the opensslv.h is in the directory freebsd/crypto/openssl/crypto. It seems that some makefile magic would install it to openssl/opensslv.h for the normal non-libbsd case (most likely the "link" rule in freebsd/crypto/openssl/crypto/Makefile). >>> ah, I see. Then I can't think of any better solution than to make a >>> rule something like you did that will copy the header file into an >>> appropriate location of the build tree. The other alternative would be >>> to create a softlink include/openssl in the source tree, effectively >>> doing what the freebsd makefile would do during a build. >> >> I have shortly thought about that too. I think I've seen some functions >> in waf that might could create that softlink. But I had two problems >> with that: >> >> 1. Like I said, I have seen some functions that _might_ could create a >> link but I'm not sure what would be the best and correctest way. Any hints? > > Could a waf 'subst' target be made to work? > > https://github.com/waf-project/waf/tree/master/demos/subst I'll take a look at that. But you know that I'm still learning about waf so it will need some time. > >> 2. I have no idea how well that would work on a Windows build host. I >> know that at least msys2 doesn't support soft links out of the box. They >> are replaced by a copy. Any experience regarding that? > > I would avoid a symlink. > > Either of these solutions are not great but I also cannot see another way > without effecting the upstream. OK. Affecting upstream could be a little difficult in that case. Openssl is most likely used in many places and they would most likely not be happy about a change in the code organization. Regards Christian -- embedded brains GmbH 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. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd include path issue
Am 24.07.2017 um 09:11 schrieb Christian Mauderer: > > > Am 24.07.2017 um 08:59 schrieb Chris Johns: >> On 24/07/2017 00:20, Christian Mauderer wrote: >>> Am 23.07.2017 um 15:57 schrieb Gedare Bloom: On Sun, Jul 23, 2017 at 8:38 AM, Christian Mauderer wrote: > The problem here is that the opensslv.h is in the directory > freebsd/crypto/openssl/crypto. It seems that some makefile magic would > install it to openssl/opensslv.h for the normal non-libbsd case (most > likely the "link" rule in freebsd/crypto/openssl/crypto/Makefile). > ah, I see. Then I can't think of any better solution than to make a rule something like you did that will copy the header file into an appropriate location of the build tree. The other alternative would be to create a softlink include/openssl in the source tree, effectively doing what the freebsd makefile would do during a build. >>> >>> I have shortly thought about that too. I think I've seen some functions >>> in waf that might could create that softlink. But I had two problems >>> with that: >>> >>> 1. Like I said, I have seen some functions that _might_ could create a >>> link but I'm not sure what would be the best and correctest way. Any hints? >> >> Could a waf 'subst' target be made to work? >> >> https://github.com/waf-project/waf/tree/master/demos/subst > > I'll take a look at that. But you know that I'm still learning about waf > so it will need some time. Hm. It seems for me that the subst would substitute some text in a source file with some other text and generate a target from it. So that most likely could be a nice replacement for the network-config.h (which is just above my new rule and uses some sed magic) but it seems a little overkill for just copying files. Maybe I also haven't found the right documentation for that to find the best function for it. The waf_generator.py generates the libbsd_waf.py. In that file, the build(bld) function is defined and we use the bld object to add some build rules (like my shell command to copy a file). But who calls the build() function and what type has the bld-object. Is there some API documentation for that object? > >> >>> 2. I have no idea how well that would work on a Windows build host. I >>> know that at least msys2 doesn't support soft links out of the box. They >>> are replaced by a copy. Any experience regarding that? >> >> I would avoid a symlink. >> >> Either of these solutions are not great but I also cannot see another way >> without effecting the upstream. > > OK. Affecting upstream could be a little difficult in that case. Openssl > is most likely used in many places and they would most likely not be > happy about a change in the code organization. > > Regards > > Christian > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Can't enable a dummy clock driver
2017-07-24 8:56 GMT+02:00 Denis Obrezkov : > 2017-07-24 8:27 GMT+02:00 Hesham Almatary : > >> On Mon, Jul 24, 2017 at 8:27 AM, Joel Sherrill wrote: >> > >> > >> > On Jul 23, 2017 5:15 PM, "Denis Obrezkov" >> wrote: >> > >> > 2017-07-23 22:30 GMT+02:00 Joel Sherrill : >> >> >> >> Increasing the stack size effectively eliminated a data corruption >> issue. >> >> The memory corrupted likely was an RTEMS internal object structure. >> >> >> >> What is the stack frame size required by each subroutine call? >> > >> > How can I determine it? >> > >> > >> > If it isn't directly in the CPU's ABI definition, then what is pushed >> to the >> > stack or reserved on each subroutine call. You may see it in terms of >> stack >> > pointer, frame pointer, reserved space, etc. >> > >> > For example, the m68k had a minimum of 4 registers saved and the return >> > address. More registers could be saved for complicated methods. >> > >> > I think some risc CPU has a number like 172 bytes reserved for possible >> > register saves. >> > >> > So the scheme varies >> > >> >> >> >> How much stack to call printf()? >> >> >> >> The minimum is an educated guess by the porter that is large enough to >> run >> >> many/most small applications. You should be able to call RTEMS >> services and >> >> do a context switch. >> >> >> >> Hope that helps pick one. :) >> > >> > >> > As for now, I have increased the minimum stack size and get the >> following >> > output: >> > >> > *** LOW MEMORY CLOCK TICK TEST *** >> > >> > TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 >> > >> > TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 >> > >> > TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 >> > >> > I will try to determine how to proceed further. >> > >> Do you configure RISC-V to get timer (or any) interrupts? You might >> want to disable all sources of interrupts, and make sure no interrupts >> are generated at all, just to figure out if the problem is with >> interrupt handling (including context save/restore). >> >> >> > >> > >> > -- >> > Regards, Denis Obrezkov >> > >> > >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >> >> >> -- >> Hesham >> > Interrupts are disabled. > > > -- > Regards, Denis Obrezkov > Also, though I did almost everything like in v850sim and RISC-V generic examples, my dummy clock driver doesn't tick. It seems to me that clock_driver_sim_idle_body just never runs. Should I try to implement an interrupt driven clock? -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Can't enable a dummy clock driver
2017-07-24 20:36 GMT+02:00 Joel Sherrill : > > > On Jul 24, 2017 2:28 PM, "Denis Obrezkov" wrote: > > 2017-07-24 8:56 GMT+02:00 Denis Obrezkov : > >> 2017-07-24 8:27 GMT+02:00 Hesham Almatary : >> >>> On Mon, Jul 24, 2017 at 8:27 AM, Joel Sherrill wrote: >>> > >>> > >>> > On Jul 23, 2017 5:15 PM, "Denis Obrezkov" >>> wrote: >>> > >>> > 2017-07-23 22:30 GMT+02:00 Joel Sherrill : >>> >> >>> >> Increasing the stack size effectively eliminated a data corruption >>> issue. >>> >> The memory corrupted likely was an RTEMS internal object structure. >>> >> >>> >> What is the stack frame size required by each subroutine call? >>> > >>> > How can I determine it? >>> > >>> > >>> > If it isn't directly in the CPU's ABI definition, then what is pushed >>> to the >>> > stack or reserved on each subroutine call. You may see it in terms of >>> stack >>> > pointer, frame pointer, reserved space, etc. >>> > >>> > For example, the m68k had a minimum of 4 registers saved and the return >>> > address. More registers could be saved for complicated methods. >>> > >>> > I think some risc CPU has a number like 172 bytes reserved for possible >>> > register saves. >>> > >>> > So the scheme varies >>> > >>> >> >>> >> How much stack to call printf()? >>> >> >>> >> The minimum is an educated guess by the porter that is large enough >>> to run >>> >> many/most small applications. You should be able to call RTEMS >>> services and >>> >> do a context switch. >>> >> >>> >> Hope that helps pick one. :) >>> > >>> > >>> > As for now, I have increased the minimum stack size and get the >>> following >>> > output: >>> > >>> > *** LOW MEMORY CLOCK TICK TEST *** >>> > >>> > TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 >>> > >>> > TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 >>> > >>> > TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 >>> > >>> > I will try to determine how to proceed further. >>> > >>> Do you configure RISC-V to get timer (or any) interrupts? You might >>> want to disable all sources of interrupts, and make sure no interrupts >>> are generated at all, just to figure out if the problem is with >>> interrupt handling (including context save/restore). >>> >>> >>> > >>> > >>> > -- >>> > Regards, Denis Obrezkov >>> > >>> > >>> > >>> > ___ >>> > devel mailing list >>> > devel@rtems.org >>> > http://lists.rtems.org/mailman/listinfo/devel >>> >>> >>> >>> -- >>> Hesham >>> >> Interrupts are disabled. >> >> >> -- >> Regards, Denis Obrezkov >> > > Also, though I did almost everything like in v850sim and RISC-V generic > examples, my dummy clock driver > doesn't tick. It seems to me that clock_driver_sim_idle_body just never > runs. > Should I try to implement an interrupt driven clock? > > > Eventually you need to but if this doesn't run, something is broken. Is > the configuration magic in bsp.h done? What's the configures is thread body? > > > > -- > Regards, Denis Obrezkov > > > Yes, I added required lines in bsp.h and in Makefile.am. Now, I think that something broken during drivers initialization. I just remembered that I wasn't able to configure a low ticker app without a console driver. And I can see now that the console driver configuration process ends with RTEMS_INTERNAL_ERROR. I think I will try again to debug a clock driver without a console driver . -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] posix: replace mmap mappings lock with libio lock
Use the libio mutex lock instead of the mmap mappings lock.
Updates #2859.
---
cpukit/posix/include/rtems/posix/mmanimpl.h | 11 +++-
cpukit/posix/src/mmap.c | 82 ++---
cpukit/posix/src/munmap.c | 6 +--
3 files changed, 13 insertions(+), 86 deletions(-)
diff --git a/cpukit/posix/include/rtems/posix/mmanimpl.h
b/cpukit/posix/include/rtems/posix/mmanimpl.h
index bb33ac9..ff59d91 100644
--- a/cpukit/posix/include/rtems/posix/mmanimpl.h
+++ b/cpukit/posix/include/rtems/posix/mmanimpl.h
@@ -39,8 +39,15 @@ typedef struct mmap_mappings_s {
extern rtems_chain_control mmap_mappings;
-bool mmap_mappings_lock_obtain( void );
-bool mmap_mappings_lock_release( void );
+static inline void mmap_mappings_lock_obtain( void )
+{
+ rtems_libio_lock();
+}
+
+static inline void mmap_mappings_lock_release( void )
+{
+ rtems_libio_unlock();
+}
#ifdef __cplusplus
}
diff --git a/cpukit/posix/src/mmap.c b/cpukit/posix/src/mmap.c
index ae68901..8f47d3b 100644
--- a/cpukit/posix/src/mmap.c
+++ b/cpukit/posix/src/mmap.c
@@ -28,85 +28,11 @@
#include
#include
-#define RTEMS_MUTEX_ATTRIBS \
- (RTEMS_PRIORITY | RTEMS_SIMPLE_BINARY_SEMAPHORE | \
- RTEMS_NO_INHERIT_PRIORITY | RTEMS_NO_PRIORITY_CEILING | RTEMS_LOCAL)
/**
- * Mmap chain of mappings.
+ * mmap chain of mappings.
*/
-rtems_chain_control mmap_mappings;
-
-/**
- * The id of the MMAP lock.
- */
-static rtems_id mmap_mappings_lock;
-
-/**
- * Create the lock.
- */
-static
-bool mmap_mappings_lock_create(
- void
-)
-{
- /*
- * Lock the mapping table. We only create a lock if a call is made. First we
- * test if a mapping lock is present. If one is present we lock it. If not
- * the libio lock is locked and we then test the mapping lock again. If not
- * present we create the mapping lock then release libio lock.
- */
- /* FIXME: double-checked locking anti-pattern. */
- if ( mmap_mappings_lock == 0 ) {
-rtems_status_code sc = RTEMS_SUCCESSFUL;
-rtems_chain_initialize_empty( &mmap_mappings );
-rtems_semaphore_obtain( rtems_libio_semaphore,
-RTEMS_WAIT, RTEMS_NO_TIMEOUT );
-/* FIXME: account for semaphore in confdefs, or maybe just use the
- * rtems_libio_semaphore? */
-if ( mmap_mappings_lock == 0 )
- sc = rtems_semaphore_create( rtems_build_name( 'M', 'M', 'A', 'P' ),
- 1,
- RTEMS_MUTEX_ATTRIBS,
- RTEMS_NO_PRIORITY,
- &mmap_mappings_lock );
-rtems_semaphore_release( rtems_libio_semaphore );
-if ( sc != RTEMS_SUCCESSFUL ) {
- errno = EINVAL;
- return false;
-}
- }
- return true;
-}
-
-bool mmap_mappings_lock_obtain(
- void
-)
-{
- if ( mmap_mappings_lock_create( ) ) {
-rtems_status_code sc;
-sc = rtems_semaphore_obtain( mmap_mappings_lock,
- RTEMS_WAIT, RTEMS_NO_TIMEOUT );
-if ( sc != RTEMS_SUCCESSFUL ) {
- errno = EINVAL;
- return false;
-}
- }
- return true;
-}
-
-bool mmap_mappings_lock_release(
- void
-)
-{
- rtems_status_code sc;
- sc = rtems_semaphore_release( mmap_mappings_lock );
- if (( sc != RTEMS_SUCCESSFUL ) && ( errno == 0 )) {
-errno = EINVAL;
-return false;
- }
- return true;
-}
+CHAIN_DEFINE_EMPTY( mmap_mappings );
void *mmap(
void *addr, size_t len, int prot, int flags, int fildes, off_t off
@@ -307,9 +233,7 @@ void *mmap(
return MAP_FAILED;
}
- /* Lock access to mmap_mappings. Sets errno on failure. */
- if ( !mmap_mappings_lock_obtain( ) )
-return MAP_FAILED;
+ mmap_mappings_lock_obtain();
if ( map_fixed ) {
rtems_chain_node* node = rtems_chain_first (&mmap_mappings);
diff --git a/cpukit/posix/src/munmap.c b/cpukit/posix/src/munmap.c
index 6bd79cc..fb9bb87 100644
--- a/cpukit/posix/src/munmap.c
+++ b/cpukit/posix/src/munmap.c
@@ -52,11 +52,7 @@ int munmap(void *addr, size_t len)
return -1;
}
- /*
- * Obtain the mmap lock. Sets errno on failure.
- */
- if ( !mmap_mappings_lock_obtain( ))
-return -1;
+ mmap_mappings_lock_obtain();
node = rtems_chain_first (&mmap_mappings);
while ( !rtems_chain_is_tail( &mmap_mappings, node )) {
--
2.7.4
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] posix: fix warnings with mmap from heap/wkspace
Avoid void pointer arithmetic. Updates #2859. --- cpukit/posix/src/shmheap.c| 2 +- cpukit/posix/src/shmwkspace.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/posix/src/shmheap.c b/cpukit/posix/src/shmheap.c index 47f5b47..b36fc28 100644 --- a/cpukit/posix/src/shmheap.c +++ b/cpukit/posix/src/shmheap.c @@ -105,6 +105,6 @@ void * _POSIX_Shm_Object_mmap_from_heap( return NULL; } - return &(shm_obj->handle[off]); + return (char*)shm_obj->handle + off; } diff --git a/cpukit/posix/src/shmwkspace.c b/cpukit/posix/src/shmwkspace.c index bcef353..cfe4d01 100644 --- a/cpukit/posix/src/shmwkspace.c +++ b/cpukit/posix/src/shmwkspace.c @@ -90,6 +90,6 @@ void * _POSIX_Shm_Object_mmap_from_workspace( return NULL; } - return &(shm_obj->handle[off]); + return (char*)shm_obj->handle + off; } -- 2.7.4 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd include path issue
On 25/07/2017 03:09, Christian Mauderer wrote: > Hm. It seems for me that the subst would substitute some text in a > source file with some other text and generate a target from it. So that > most likely could be a nice replacement for the network-config.h (which > is just above my new rule and uses some sed magic) but it seems a little > overkill for just copying files. > > Maybe I also haven't found the right documentation for that to find the > best function for it. The waf_generator.py generates the libbsd_waf.py. > In that file, the build(bld) function is defined and we use the bld > object to add some build rules (like my shell command to copy a file). > But who calls the build() function and what type has the bld-object. Is > there some API documentation for that object? > I think this is the example: https://github.com/waf-project/waf/blob/master/demos/subst/wscript#L33 Also Section 6.3.3 of the Waf Book ... https://waf.io/book/#_buildcontext_specific_methods Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: parallel make failure?
On 22/07/2017 02:55, Kirspel, Kevin wrote: > I have seen similar things as well. In my case it fails in different places > randomly. Sometimes it will get all the way through. Do you mean a similar preinstall error but in a different location in the source tree? I am wondering if this is common or specific to some places. The change to unroll the loops we use to have means we need to fix any broken dependences. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/1] rtems-tools: Add rtems-test scripts for standalone sis
On 22/07/2017 06:30, Jiri Gaisler wrote: > Can somebody review and merge this to rtems-tools.git? Pushed. Thanks. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
