Proposal for internal Shark interface change -------------------------------------------- This little notes collects some impressions I have on the scheduling modules architecture. It is a long time that I have some of these feelings, so I want to share them with all the people that uses the kernel, to have (I hope) useful suggestions. Please mail me all the suggestions you have, also those that implies -big- changes into the kernel... - Task Queue handling ----------------------------------------------------------------------- Until a few weeks ago, task queue handling was done using the QUEUE and QQUEUE types. They are (I hope) quite simple, however there is a disadvantage, the side effect the functions have on the task descriptor; the next, prev, priority and timespec_priority fields are in fact modified by the functions. Although this side effect is very clear to me, unfortunately I saw many times people (mainly students) trying to insert a task in more than one queue, or some other bad things. As a result, the kernel crashes without giving any clue of the reason. To insert a task in more than one queue, in the past I solved writing again another function for queuing tasks... and that is of course not the best solution. Anyway sometimes is useful to: - insert a task in more than one queue (see hyerarchical scheduling) - check if a task is inserted or not in a queue - handle a queue like an abstract data type For that reason I developed a new abstract data type called IQUEUE, and I removed the QUEUE and the QQUEUE types. the results can be seen in the latest snapshot... The advantages of the current implementation are: - the queuing fields and the priorities can be shared between queues or they can be private - there should be no problem in checking if a task is already inserted in a queue, since all that remains into the implementation of the abstract data type IQUEUE the only problem that I can see is that the query function names are a little bit too verbose (iq_query_timespec....), anyway since they are inline function it should not be a big problem. Note that all the modules have to be rewritten to consider the new data types. The modifications are often a change from q_* and qq_* to iq_*, plus the initialization that is forced... usually an iq_init(&myqueue, &freedesc, 0) works for all the modules that where written before the change. Guest Calls, Task Calls e Level Calls ----------------------------------------------------------------------- The main issue is: How can we reduce/ simplify/ optimize the functions that a user have to write to create a new scheduling module? The guideline that I have in mind is to create an interface - basically similar to the current one - where -all- the functions are better defined - that will allow for a future dynamic loading of modules (that is, no functions like EDF_usedbandwidth (see kernel/modules/edf.c; only function pointers) - where the module should define only the functions that it uses (now, a module usually defines -all- the interface) - any other ideas? Some ideas... 1) remove task_delay/guest_delay Rationale: it exists a nanosleep function that does the same thing. Task delay was inherited by the old Hartik kernel, and it was not so often used. -------------------------------------------------- 2) substitute task_sleep + task_endcycle with only one function with a prototype like: void (*task_message)(LEVEL l, PID p, void *msg); and then remap - task_sleep -> task_message(l,p,NULL) - task_endcycle -> task_message(l,p,1) Rationale: I often read about the fact that "endcycle" and "sleep" are only meaningful if a task is periodic... that is, it is an application behavior that can be resolved in may other ways (example: POSIX uses sigwait+timers). However, in shark the scheduling is incorporated into the modules, that runs in "kernel space" (that is simply with interrupt disabled). In that case it can be often useful to implement a way to send some information to the scheduler, that can be slee, endcycle, or something else. Having a generic "message" function simplifies the module implementation, also maybe removing the need of a EDF_usedbandwidth function. QUESTION: should the message be only sent to the running task (think at a function like task_endcycle() ) or to a specific task? -------------------------------------------------- 3) Guest calls Guest calls are currently used by aperiodic servers to insert tasks into other master modules. I'm thinking at reducing the number of guest calls to 4: - guest_create --> creates and activates a task into a master module - guest_end --> removes a task from a master module - guest dispatch --> informs the master module that a guest task has been dispatched - guest_epilogue --> informs the master module that a guest task has been preempted QUESTIONS: - what about guest_insert/guest_extract? well... they currently have a behavior similar to task_insert/task_extract, but I'm not sure they are really needed. In fact, insertion/extraction can be andled by the aperiodic server, that only propagates to the master module the right functions (end or epilogue in case of task_extract, create or dispatch in case of task_insert) - should we maintain the level_des descriptor like that (level calls+guest calls+task calls) or should we change it to something else (level calls+task calls on one descriptor, +guest calls on an extension... or what else?) (I'm currently thinking to leave the structure as is now, because it needs less checks...) (see proposal 6) -------------------------------------------------- 4) level_accept_*_model I think we can remove them, because: - task_create can do the job of level_accept_task_model without any big problems - level_accept_guest_model has NEVER been used!!!! -------------------------------------------------- 5) pclass and devil's OR As you noted, pclasses are in the form XX00 because I wanted to discriminate the leve to which a task model should have been accepted. I'm thinking to add a "level" number to the TASK_MODEL. It does not introduce any overhead, and it should be more clear (mainly useful when explaining task models to the students ;-) ) -------------------------------------------------- 6) Optional specification of functions into the Kernel Now when I write a module I have to specify all the pointer to functions. I would like to change the level_alloc_descriptor in a way that it uses kern_alloc to allocate the data structure, initializing it to some default function values, that are functions that raise an exception. In that way: - a module have only to redefine the function it uses (as done also in MarteOS ;-) (see http://marte.unican.es). - there is not a big need to split the level descriptor in different parts (see proposal 3) -------------------------------------------------- 7) task_eligible It is really needed?... well I still thinking at it. And it is needed sometimes when using CBS in conjunction with other ill-behaved scheduling modules. -------------------------------------------------- 8) level_guarantee has a few problems: - the type bandwidth_t does not handle utilizations > 1 (what can we use, since floating point cannot be used?) Another result of that is the famous ugly "FAILED_GUARANTEE" bit in many scheduling modules (it always took me a few minutes for explaining that trick; see again kernel/modules/edf.c)... - is it really useful? (when implementing complicated scheduling algorithms, it often unusable... maybe it can only be used to do \[ \sum{\frac{C_i}{T_i)\leq 1 \] (excuse for the Latex typos) - since the global guarantee() function start with 1 decreasing the used bandwidth, why not asking directly to the module that accepted the task if it can accept an increment in its bandwidth? -------------------------------------------------- 9) level_status Also that function is inherited from the old Hartik. Anyone is interested in it? could we remap it to the message task call (see proposal 2)??? (in fact, almost noone used the task_status primitive... but anyway, should we provide something to inquire the status of a module or of a tsak? and in which way?) --------------------------------------------------