RE: abstraction layer where?

[Volkmar Uhlig]

> -----Original Message-----
> From: Marcus Brinkmann [mailto:address@hidden 
> Sent: Sunday, May 18, 2003 4:12 AM
> 
> do we want to use a common (or at least very similar) 
> interface definition
> for Hurd on Mach, on L4 and what not?  Because I was thinking 
> that if we
> write different interfaces, we can do better optimization and hide the
> differences in the libraries.
> 
> For example, auth returns four arrays.  On L4 I am tempted to 
> just put a limit of 62 for nr_egids + nr_agids + nr_euids + nr_auids 
> and define the get_ids interface to
> [...snip...]
> 
> If we need more ids, then we can always make this call fail 
> quickly and let the user follow up with a different call that 
> uses string items and cache lines or mapped memory.  But 
> normally 62 should be plenty.
>
> I am thinking about such stuff and realize that this could be 
> difficult to express in an IDL.  However, it might be worthwhile 
> to hand optimize at least some central servers this way, ie auth, 
> proc, etc.  The C interface (ie, libhurduser) could in this case 
> even be identical to the current one
> (except with the optional MR2 input arg).  We have various libraries,
> libps, libiohelp, libfshelp etc which can further hide the 
> differences.

Marcus,

I believe you try to tweak the wrong knobs. It is not the programmer
which should do this hand-optimization but the IDL compiler. The IDL
compiler should know in what cases it is more efficient to use MRs and
when to use indirect strings. Usually there is a tradeoff, when indirect
copying is cheaper than direct copying, and that is probably not 63 MRs,
but somewhere around 30. 
Therefore, this is not only different per API but also per
processor/ABI. So I would suggest a single IDL (which does not put
constraints on the IDL compiler) and have the IDL compiler perform the
optimizations. Maybe have a look at [1] and potential optimization
space.

- Volkmar

[1]
http://i30www.ira.uka.de/teaching/thesisdocuments/haeberlen_study_idl4op
t.pdf