I discovered some warnings…especially the last one seems to be a real problem
hwtimer_cpu.c:243:55: warning: unused parameter ‘fcpu’ [-Wunused-parameter]
void hwtimer_arch_init(void (*handler)(int), uint32_t fcpu)
irq_cpu.c:295:43: warning: unused parameter ‘info’ [-Wunused-parameter]
void native_isr_entry(int sig, siginfo_t *info, void *context)
cc110x_ng_cpu.c:270:30: warning: unused parameter ‘c’ [-Wunused-parameter]
uint8_t write_single(uint8_t c)
mutex.c:94:46: warning: unused parameter ‘yield’ [-Wunused-parameter]
void mutex_unlock(struct mutex_t *mutex, int yield)
vtimer.c:80:24: warning: unused parameter ‘ptr’ [-Wunused-parameter]
void vtimer_tick(void *ptr)
vtimer.c:112:28: warning: unused parameter ‘ptr’ [-Wunused-parameter]
void vtimer_callback(void *ptr)
hwtimer_cpu.c:243:55: warning: unused parameter 'fcpu' [-Wunused-parameter]
void hwtimer_arch_init(void (*handler)(int), uint32_t fcpu)
fcpu is a scaling parameter for certain architectures (like ARM). Should explicitly ignore by other MCUs to get rid of the compiler warning.
mutex.c:94:46: warning: unused parameter 'yield' [-Wunused-parameter]
void mutex_unlock(struct mutex_t *mutex, int yield)
Maybe deprecated.
`vtimer.c:80:24: warning: unused parameter ‘ptr’ [-Wunused-parameter]
void vtimer_tick(void *ptr)
vtimer.c:112:28: warning: unused parameter ‘ptr’ [-Wunused-parameter]
void vtimer_callback(void *ptr)`
ptr is necessary to implement hwtimer callback.
irq_cpu.c:295:43: warning: unused parameter ‘info’ [-Wunused-parameter]
void native_isr_entry(int sig, siginfo_t *info, void *context)
Can be explicitly ignored to get rid of the warning.
Hey,
>mutex.c:94:46: warning: unused parameter 'yield' [-Wunused-parameter]
void mutex_unlock(struct mutex_t *mutex, int yield)|
Maybe deprecated.
Lets think this through. I checked the history, we actually honoured that flag before.
This parameter allows control over the yield behavior on mutex unlocking, e.g., whether a task switch is forced within mutex_unlock or not. This saves context switches if you have to release more than one mutex before yielding, or whether you just want to notify a lower-priority thread, but have work to do before. With our scheduling policy in mind, this only makes sense for other threads with the same priority:
1. We unlock, only lower threads waiting -> yield comes right back.
2. We unlock, only higher threads waiting -> scheduling policy requires instant yield.
3. We unlock, other thread with same priority waiting -> we wouldn't yield unless forced, but we have to do the check for higher priority threads anyways.
So I guess you're right, the parameter is obsolete. Intended behaviour can be replicated by explicitly calling sched_yield() after mutex_unlock().
We should not remove the parameter before the next major version as the change breaks the API.
Am I wrong?
Cheers,
Kaspar
Hi Kaspar,
>void mutex_unlock(struct mutex_t *mutex, int yield)|
>Maybe deprecated.
Lets think this through. I checked the history, we actually honoured
that flag before.
<snip>
We should not remove the parameter before the next major version as
the change breaks the API.
Am I wrong?
sounds reasonable for me.
Cheers,
Oleg