This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, newlib] Allow locking routine to be retargeted


Hi!

I'm not Sebastian, but I took the liberty to give an opinion here.
Option 1 brings almost nothing, as you have to make sure the toolchain
you use supports the RTOS you want to use. If it doesn't you have to
build your own. If you have to build your own, then you can as well
just integrate locks without this change...

As for the option 2 I guess that it would be perfectly reasonable to
declare some kind of startup function that should be called by user's
RTOS.

I have just thought about another idea:
1. Newlib would define - in a public header - number of required
recursive and non-recursive statically allocated locks:
#define AMOUNT_OF_STATIC_LOCKS 5
#define AMOUNT_OF_STATIC_RECURSIVE_LOCKS 3
2. In the same header it would define functions like "void*
get_lock(size_t index)" and "void* get_recursive_lock(size_t index)".
3. In some private newlib header there would be assignments of indexes
with locks like:
#define MALLOC_RECURSIVE_LOCK 0
#define STDIO_RECURSIVE_LOCK 1
...
#define TZ_LOCK 0
#define WHATEVER_LOCK 1
...
4. All uses of locks like:
__lock_acquire_recursive(__malloc_lock);
would have to be changed to:
__lock_acquire_recursive(get_recursive_lock(MALLOC_RECURSIVE_LOCK));


This way the user could just have in his own RTOS a nice array of locks
with proper size and automatic amount of elements. More advantages:
- by having two functions and two defines we could easily have
recursive and non-recursive locks;
- we could just drop __LOCK_INIT and add a requirement for user to
initialize the locks;

What do you think?

Regards,
FCh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]