Schedule Groups

[Habeeb P]

Hello,

I am reading through muen tool chain source code;
In mugenspec tool you generate the scheduling group IDs and  creating reverse group ID to subject ID mappings.

Please explain me, what is the purpose of scheduling group ID and Scheduling_Group_Array.


One more doubt,


 In spec-skp_scheduling.adb  file one scheduling_Groups array is  creating with size  (1 .. Last_Group_ID)   and the value of Last_Group_ID = Next_Free_Group_ID - 1
 by using following code segment,

line 422         Last_Group_ID     : constant Natural := Next_Free_Group_ID - 1;
line 423         Scheduling_Groups : array (1 .. Last_Group_ID) of Natural;

Next_Free_Group_ID declared with initial value 1, 

line 122        Next_Free_Group_ID  : Positive         := 1;

and  value of Next_Free_Group_ID incrementing  by following code

         

line 331       if Subject_To_Group_ID (Subject_Id) = No_Group then

                   --  Subject belongs to new scheduling group.

                    Subject_To_Group_ID (Subject_Id) := Next_Free_Group_ID;
                    Next_Free_Group_ID := Next_Free_Group_ID + 1;
line 337       end if;

My question is, How the size of Scheduling_Groups array become (1 .. 6) ?   (Is there any other code incrementing value of Next_Free_Group_ID variable?)

line 422         Last_Group_ID     : constant Natural := Next_Free_Group_ID - 1;
line 423         Scheduling_Groups : array (1 .. Last_Group_ID) of Natural;

After building skp-scheduling.ads containing following defenition,

 Scheduling_Groups : constant Scheduling_Group_Array
     := Scheduling_Group_Array'(
          1 => 0,
          2 => 1,
          3 => 5,
          4 => 6,
          5 => 4,
          6 => 7);

Thank You
HABEEB P

[Adrian-Ken Rueegsegger]

Hi,

On 09/20/2016 09:54 AM, Habeeb P wrote:
> I am reading through muen tool chain source code;

Great to hear that you are diving into the Muen code!

> In *mugenspec* tool you generate the *scheduling group ID*s and creating *reverse
> group ID* to subject ID mappings.
>
> Please explain me, what is the purpose of *scheduling group ID *and
> *Scheduling_Group_Array.

What we mean by scheduling group is a set of subjects that can perform
cooperative scheduling in the minor frames assigned to that group.
Within that group of subjects only one is the currently active subject.
Switching between the different members of the scheduling group is
achieved via handover events.

So each minor frame of a scheduling plan references a scheduling group
and the currently active subject of that group is scheduled during that
minor frame. To give an example of a scheduling group: a Linux subject
and the corresponding subject monitor form a scheduling group.

The Scheduling_Groups constant towards the bottom of the Skp.Scheduling
package specifies for each scheduling group which subject is initially
active and is to be executed in the minor frames that are allotted to
the scheduling group with the given ID.

> One more doubt,*
>
> In *spec-skp_scheduling.adb *file one *scheduling_Groups* array is
> creating with size * (1 .. Last_Group_ID)* and the value of*
> Last_Group_ID = Next_Free_Group_ID - 1*

> by using following code segment,
>
> line 422 Last_Group_ID : constant Natural := Next_Free_Group_ID
> - 1;
> line 423 Scheduling_Groups : array (1 .. Last_Group_ID) of Natural;
>

> *Next_Free_Group_ID *declared with initial value 1,

>
> line 122 Next_Free_Group_ID : Positive := 1;
>

> and value of *Next_Free_Group_ID *incrementing by following code
>
> *line 331 if Subject_To_Group_ID (Subject_Id) = No_Group then

> -- Subject belongs to new scheduling group.
> Subject_To_Group_ID (Subject_Id) := Next_Free_Group_ID;

> Next_Free_Group_ID := Next_Free_Group_ID + 1;line 337 end if;*
> *My question is, *How the size of *Scheduling_Groups* array become (1 .. 6)

> ? (Is there any other code incrementing value of Next_Free_Group_ID
> variable?)

Currently scheduling groups are not explicitly defined in the XML system
policy but are instead implicitly given by the wiring of handover events
between subjects. The subject references of minor frames in the
<scheduling> section of the policy specify the initially active subject
of the corresponding scheduling group. So if you look at the
policy/xml/common_scheduling.xml file you see that there are references
to six different subjects in all minor frames. That is equal to the
number of scheduling groups.

The code in Mugenspec traverses the XML scheduling spec and determines
the number of scheduling groups by counting the number of distinct
subject references.

Note that the scheduling part of the policy and the scheduling groups in
particular may change in the future, e.g. become explicitly defined by
the policy writer.

I hope the provided information helps to clarify your questions.

Regards,
Adrian

[Habeeb P]

Hi,
 
Thanks for the detailed reply.

Some more doubts;

1. What is the use of slots in VT subject? I know that there exist six slots in VT.

2. While handling external interrupts (eg: keyboard interrupt),  VT subject first write the event information to channel, then only trigger the hypercall event (as shown in below code).  Is it secure to allow a subject to write into a channel  without using muen kernel?
  

// mux-channels.adb

procedure Write
     (Channel : Output_Channel_Range;
      Event   : Input.Input_Event_Type)
   is
   begin
      Input_Event_Channel_Wtr.Write
        (Channel => Out_Channels (Channel),
         Element => Event);
      SK.Hypercall.Trigger_Event (Number => SK.Byte (Channel));
   end Write;

3. If you have, please share me documentation of SHMStream v2 protocol.


Thanking You
HABEEB P

[Adrian-Ken Rueegsegger]

Hello,

On 10/03/2016 07:36 AM, Habeeb P wrote:
> 1. What is the use of slots in VT subject? I know that there exist six
> slots in VT.

The VT (virtual terminal) subject provides several slots. Each slot is
associated with specific subjects and can be made active/selected via
the F[1-6] keys. The VT displays the output of the currently active
subject on the screen. Keyboard input is also forwarded to the subject
associated with the active slot. In the case of the demo system the NIC
Linux is on slot 1 and the Storage Linux on slot 2. You can switch
between the two by pressing the F1 and F2 keys.

> 2. While handling external interrupts (eg: keyboard interrupt), VT subject
> first write the event information to channel, then only trigger the
> hypercall event (as shown in below code). Is it secure to allow a subject
> to write into a channel without using muen kernel?

It is safe in the sense that the data flow between the reader and writer
of the channel must be specified in the system policy. Thus, if a
subject is able to use (i.e. read and or write to) a channel, the system
integrator has explicitly granted the subject access to this resource. A
subject has no access to resources that are not assigned to it in the
system policy. In the case of channels, which are basically just shared
memory, there are no mappings present for channels that are not assigned
to a given subject.

Since the system is static during runtime there is no need for the
kernel to perform any kind of access check when a subject operates on a
channel resource.

> 3. If you have, please share me documentation of *SHMStream v2 protoco*l.

We added the document to the repository under doc/shmstream, see the
current devel branch [1].

Hope this helps,
Adrian

[1] - https://git.codelabs.ch/?p=muen.git;a=tree;f=doc/shmstream;hb=c19e48c