All,

On 2007-02-04, sancho1980 wrote:
> hi
> could someone please explain me these lines from the source:
>
> 06056 #define TSK_T (1 << RECEIVE) /* clock and
> system */
> 06057 #define SRV_T (~0) /* system
> services */
> 06058 #define USR_T ((1 << SENDREC) | (1 << ECHO)) /* user
> processes */
>
> 1. whats that in the first line? RECEIVE is defined as 2 so TSK_T ends
> up being defined as 4. what a statement is that on the allowed kernel
> traps for tasks, i dont get it...

It's allowed to do a RECEIVE trap. It's a bitmask.

> 2. what processes does SRV_T refer to. afaik, tasks are also system
> processes, does that mean they too may make all kinds of traps (which
> would render the definition of TSK_T pointless)

You can see which processes can do TSK_T traps and which processes
can do SRV_T traps by looking at the 'traps' field in image[].
TSK_T processes are:
{CLOCK,clock_task,TSK_F, 8, TASK_Q, TSK_S, TSK_T, 0, no_c,"clock" },
{SYSTEM, sys_task,TSK_F, 8, TASK_Q, TSK_S, TSK_T, 0, no_c,"system"},
so clock and system only use the RECEIVE trap.

Of course clock and system also do other IPC functions, but because
they're in the same address space as the kernel, they call the internal
IPC functions directly (with interrupts disabled - the lock_* variants)
to do this, and don't need to trap.

> 3. same question as under point 1 for the third line: what does USR_T
> imply for user processes, looks a bit cryptic to mee

User processes are allowed to do SENDREC and ECHO. The
(1 << .. ) expressions are a convenient way to make a bitmask out
of a scalar value.

> btw, when i press the f4 key i get this ipc_to_mask which tells me
> which system processes a process may send to, but how do i find out
> what system process id (of the 32, not the pid) belongs to which
> system process?

The 2nd column, marked '(id)', gives the system process id for each
process.

=Ben