Add wpa supplicant command in media01.
---
testsuite/include/rtems/bsd/test/default-network-init.h | 3 ++-
testsuite/media01/test_main.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/testsuite/include/rtems/bsd/test/default-network-init.h
b/tes
Add wpa_supplicant lib support and shell command support in RTEMS.
---
builder.py | 1 +
freebsd/contrib/wpa/src/utils/os_unix.c| 11 +-
freebsd/contrib/wpa/wpa_supplicant/config.h| 3 +
freebsd/contrib/wpa/wpa_supplicant/main.c
Add fork command for wpa supplicant to start a new task.
---
freebsd/contrib/wpa/wpa_supplicant/main.c | 65 ++
libbsd.py | 1 +
libbsd_waf.py | 1 +
rtemsbsd/include/machine/rtems-bsd-comm
On 11/10/17 11:30 pm, Sebastian Huber wrote:
>
> milestones 4.13 and 5.0 don't fit the new version scheme:
>
> https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
>
>
> I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tickets to 5.1.
>
A change t
On 12/10/17 12:00 am, Sebastian Huber wrote:
> Module:rtems
> Branch:master
> Commit:16fcd56a42dfdef514350ab6297137e2c863afa1
> Changeset:
> http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1
>
> Author:Christian Mauderer
> Date: Wed Oct 11 15:38:
Am 12.10.2017 um 18:06 schrieb Chris Johns:
> On 12/10/17 12:00 am, Sebastian Huber wrote:
>> Module:rtems
>> Branch:master
>> Commit:16fcd56a42dfdef514350ab6297137e2c863afa1
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=16fcd56a42dfdef514350ab6297137e2c863afa1
>>
>> Author:
Hi,
Many thanks for post the patches. The other patches look fine. I am wondering
is this is equivalent to what you have?
diff --git a/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
b/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c
index 15a9050133..d14082691a 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-bit
Hi Chris,
Based on my understanding, the patch in your email is different:
1) rtems_rfs_bitmap_map_set:
By changing negating the if condition, the updated logic only modifies the
element map[index] when the original value of map[index] is
RTEMS_RFS_BITMAP_ELEMENT_SET.
This is not quite right, as
On 12/10/17 10:05 am, Fan Deng wrote:
> Hi Chris,
>
Thanks for quick response.
> Based on my understanding, the patch in your email is different:
>
> 1) rtems_rfs_bitmap_map_set:
> By changing negating the if condition, the updated logic only modifies the
> element map[index] when the original
On 12/10/17 9:36 am, Christian Mauderer wrote:
> Am 12.10.2017 um 18:06 schrieb Chris Johns:
>> On 12/10/17 12:00 am, Sebastian Huber wrote:
>>> @@ -4,7 +4,6 @@ RTEMS_CPU = arm
>>>
>>> CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard
>>>
>>> -CFLAGS_OPTIMIZE_V = -O2 -g
>>>
This impacts rtems_task_mode() and rtems_task_create().
updates #3000.
---
c/src/ada/rtems.ads | 3 ++-
cpukit/rtems/include/rtems/rtems/status.h | 10 --
cpukit/rtems/src/statustext.c | 1 +
cpukit/rtems/src/taskcreate.c | 19 ++
This impacts rtems_task_mode() and rtems_task_create().
Closes #3000.
---
c-user/directive_status_codes.rst | 4
c-user/task_manager.rst | 8
2 files changed, 12 insertions(+)
diff --git a/c-user/directive_status_codes.rst
b/c-user/directive_status_codes.rst
index 420a0a
Thanks Chris!
First of all let's make sure a few points are clarified:
1) What should rtems_rfs_bitmap_map_set(control, bit) do?
- 'control' is a handle to the bitmap.
- 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in
the range of [0, control->size - 1].
2) How does the b
On 12/10/17 11:46 am, Fan Deng wrote:
> Thanks Chris!
>
> First of all let's make sure a few points are clarified:
>
> 1) What should rtems_rfs_bitmap_map_set(control, bit) do?
> - 'control' is a handle to the bitmap.
> - 'bit' is the offset of the bit to set in the bitmap. 'bit' should be in the
Yes the physical state can vary depending on the configuration of the RFS.
But that is not my point here.
Let's see an example:
Assuming
- set = physical 1, so RTEMS_RFS_BITMAP_ELEMENT_SET = UINT32_MAX
- map[index]=0b
1110
Hi
For RTEMS to participate in Google Code-In, we will need mentors. Being a
GCI
mentor is different from being a GSoC or SOCIS mentor. The tasks are not
large
like the summer projects in those programs. They are small tasks which any
RTEMS user or developer (including GSoC students) can provide
Update #3182.
---
testsuites/psxtests/Makefile.am| 1 +
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxclockrealtime01/Makefile.am | 19 ++
testsuites/psxtests/psxclockrealtime01/init.c | 304 +
.../psxclockrealtim
On 12/10/17 20:45, Joel Sherrill wrote:
- RTEMS_PROXY_BLOCKING = 28
+ RTEMS_PROXY_BLOCKING = 29
I would not change existing status code values.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax
On 12/10/17 16:24, Chris Johns wrote:
On 11/10/17 11:30 pm, Sebastian Huber wrote:
milestones 4.13 and 5.0 don't fit the new version scheme:
https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
I suggest to rename the 5.0 milestone to 5.1 and move all 4.13 tick
Am 12.10.2017 um 19:42 schrieb Chris Johns:
> On 12/10/17 9:36 am, Christian Mauderer wrote:
>> Am 12.10.2017 um 18:06 schrieb Chris Johns:
>>> On 12/10/17 12:00 am, Sebastian Huber wrote:
@@ -4,7 +4,6 @@ RTEMS_CPU = arm
CPU_CFLAGS = -mthumb -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-
20 matches
Mail list logo
