ukernel complexity metrics

[Joshua LeVasseur]

Multiplexing many operations on a single syscall isn't the most 
efficient way to go about it.  And yet many operating systems do just 
that: They use a register to encode the syscall number.  And some even 
have to deal with conflicting allocations of the syscall numbers: 
Darwin multiplexes both Mach and BSD system calls, and accomplishes 
this by splitting them between negative and positive numbers.

A bit of information can be encoded into the instruction stream, 
helping to avoid allocating precious processor registers.  Thus if you 
jump straight to the routine that implements the system call, you can 
avoid allocating a register for a sub-function ID, and you can take 
advantage of the processor's branch prediction hardware that is based 
on instruction addresses.

IA64 easily supports system call implementations that jump straight to 
the routines' implementations.  It has the epc instruction.  But other 
architectures can mimic the same behavior.  I do it on PowerPC, by 
using the sc instruction to raise the privilege level of the code.  The 
user-level programs get to jump straight to the system calls' 
implementations, and the kernel raises the privilege as appropriate.  
Thus I avoid the typical table lookup and indirect function call.  I 
even eliminate more branches by placing the C++ kernel code immediately 
after their assembler prologues.

-Josh


On Feb 24, 2005, at 16:21, David Leimbach wrote:

>
> On Feb 24, 2005, at 6:52 AM, Espen Skoglund wrote:
>
>> [Jonathan S Shapiro]
>>> On Thu, 2005-02-24 at 09:15 +0100, Ronald Aigner wrote:
>>>> I disagree with the opinion that the complexity of a microkernel
>>>> should be measured by the number of its system-calls. I find it
>>>> rather complex to multiplex dozen flavours of IPC via one
>>>> systemcall.
>>
>>> I am not sure quite what motivated this comment. We have argued in
>>> the EROS design that having exactly one system call ("invoke
>>> capability", in our case) is good, but not because it reduces
>>> microkernel complexity -- in fact, it complicates it.
>>
>> Would also like to add that the reason for multiplexing all these
>> operations in the IPC mechanism is not really to reduce complexity.
>> We multiplex all these operations because the operations are similar
>> enough in nature to share the same codepath and thereby reduce the
>> cache/memory footprint of the kernel.
>>
>> I don't think anyone has ever stated that the number of system calls
>> is a measure for the *complexity* of the kernel.
>
> Just to chime in quickly here... At the most primitive levels of the 
> kernel
> everything can be multiplexed to one system call and I don't think 
> this would
> really "bother" me in trying to understand how to use the kernel 
> because it
> always seems that someone comes along and wraps that one system call 
> with
> normally very lightweight abstractions to help demystify the heavy 
> amount
> of multiplexing.
>
> In this way that perceived complexity can be reduced with little 
> overhead.
>
> Can't this sort of thing be "generated" either by macro or IDL to add 
> an
> artificial abstraction layer to make it more clear to the higher level 
> L4
> coder what exact functionality is being called upon?
>
> I'm not sure I see how heavy multiplexing has to be a problem for 
> anyone.
> If it's possible to do it all in one syscall, I'd go for it :).  After
> all increasing the complexity of the upper layers is traditionally what
> modern microkernels do but once you have a really decent library of 
> tools
> I bet a lot of the perceived complexity falls away. [maybe not so much 
> as
> to make it as "easy" to code for as a monolithic kernel but good 
> enough :)]
>
> Is this consistent with the current philosophy of microkernels?
>
> Dave
>>
>> 	eSk
>>
>>
>
>