[Cbe-oss-dev] [PATCH 05/11]MARS: Kernel syscall add get workload by id

Yuji Mano yuji.mano at am.sony.com
Sat Sep 13 07:18:28 EST 2008


Kazunori Asayama wrote:
> Yuji Mano wrote:
>> This adds a new MARS kernel syscall 'mars_get_workload_by_id' to allow for the
>> task library to grab an instance of a workload context other than the one
>> currently running. This is needed when a task waits for completion of another
>> task, and needs to obtain the exit_code of the completed task from the task
>> context.
>> 
>> This also renames the previously existing MARS kernel syscall
>> 'mars_get_workload_context' to 'mars_get_workload'.
>> 
>> Signed-off-by: Yuji Mano <yuji.mano at am.sony.com>
> 
> (snip)
> 
>> +struct mars_workload_context *workload_get_by_id(uint16_t workload_id)
>> +{
>> +	MARS_CHECK_RET(workload_id < MARS_WORKLOAD_MAX, NULL);
>> +
>> +	static struct mars_workload_context requested_workload;
>> +	uint64_t requested_workload_ea;
>> +
>> +	/* workload id is same as current workload so return local copy */
>> +	if (workload_id == workload_index)
>> +		return &workload;
>> +
>> +	/* get ea of workload to get */
>> +	requested_workload_ea = queue_header.context_ea +
>> +			workload_id * sizeof(struct mars_workload_context);
>> +
>> +	/* dma the workload context code into LS from main memory */
>> +	mars_dma_get_and_wait((void *)&requested_workload,
>> +				requested_workload_ea,
>> +				sizeof(struct mars_workload_context),
>> +				MARS_DMA_TAG);
>> +
>> +	return &requested_workload;
>> +}
>> +
> 
> The static area 'requested_workload' can be overwritten by the next
> workload_get_by_id call. Is it OK?
> 

In the current implementation this is not a problem.
But of course the caller needs to be aware that the context ptr returned
is only valid until the next call to that function. Currently the task
policy uses this only so it can get the exit_code out from the context and
does not keep the returned pointer around. 

I think this is fine for now because this syscall is available only between
the kernel and the runtime policy internal implementation and not made
available publicly.

If and when we decide to provide a custom policy module interface, this
may need to change for more flexibility.

Regards,
Yuji





More information about the cbe-oss-dev mailing list