This should be fine. It's an "internal" API so we just need to ensure
consistency in our kernel code.
On Mon, May 2, 2016 at 3:55 PM, Jeff Johnston <jjohn...@redhat.com> wrote:
> Do you have consensus with the RTEMS group for this change which breaks API
> introduced
> last year? Otherwise, I will leave it up to the RTEMS maintainers to comment.
>
> -- Jeff J.
>
> ----- Original Message -----
>> Move _Thread_queue_Queue::_Lock to begin of the structure. On RTEMS,
>> the presence of a lock component in the thread queue structures actually
>> depends on the build-time RTEMS_SMP configuration option. A move of
>> this part to the begin of the structure allows an implementation re-use
>> for the other parts.
>>
>> Signed-off-by: Sebastian Huber <sebastian.hu...@embedded-brains.de>
>> ---
>> newlib/libc/sys/rtems/include/sys/lock.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/newlib/libc/sys/rtems/include/sys/lock.h
>> b/newlib/libc/sys/rtems/include/sys/lock.h
>> index d2a7fb1..002064f 100644
>> --- a/newlib/libc/sys/rtems/include/sys/lock.h
>> +++ b/newlib/libc/sys/rtems/include/sys/lock.h
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015 embedded brains GmbH. All rights reserved.
>> + * Copyright (c) 2015, 2016 embedded brains GmbH. All rights reserved.
>> *
>> * Redistribution and use in source and binary forms, with or without
>> * modification, are permitted provided that the following conditions
>> @@ -43,8 +43,8 @@ struct _Ticket_lock_Control {
>> };
>>
>> struct _Thread_queue_Queue {
>> - struct _Thread_queue_Heads *_heads;
>> struct _Ticket_lock_Control _Lock;
>> + struct _Thread_queue_Heads *_heads;
>> };
>>
>> struct _Mutex_Control {
>> @@ -70,7 +70,7 @@ struct _Futex_Control {
>> struct _Thread_queue_Queue _Queue;
>> };
>>
>> -#define _THREAD_QUEUE_INITIALIZER { 0, { 0, 0 } }
>> +#define _THREAD_QUEUE_INITIALIZER { { 0, 0 }, 0 }
>>
>> #define _MUTEX_INITIALIZER { _THREAD_QUEUE_INITIALIZER, 0 }
>>
>> --
>> 1.8.4.5
>>
>>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
