Warning: Parameter 1 to Language::getMagic() expected to be a reference, value given in /opt/local/apache2/htdocs/wiki/includes/StubObject.php on line 58
Telecon 06-07-07 - OSR

Telecon 06-07-07

From OSR

Jump to: navigation, search

1) Long discussion about dynamic libraries

Primary benefits:

   - Users won't have to relink code continuously
   - Mechanism to provide "Linux ABI" compatibility (*)

(*) Via a special dynamically linked glibc. Same binary would run on Linux and LWK without a recompile.

Two main types of dynamic libraries:

   1) Load-time dynamic libraries
   2) Run-time dynamic libraries (dlopen())

Load time can either be pre-linked by Yod or linked on the compute node. Run-time libraries probably have to be linked at compute node. Both cases should use the same general purpose mechanism for fanning out binaries and files.

2) Discussion of system level view

Desirable to not send or receive messages from QK.

Init task provides initial job load mechanism/bootstrap. Sleeps until message arrives for it.

PCT launches application tasks. PCT provides services to tasks (handles some syscalls).

Kurt pointed out this is all very similar to K42. s/PCT/dispatcher/

Goal is to ease PCT resource management experimentation by loading PCT on a per job basis.

PCT should do task scheduling, not QK. QK will run an app task's associated PCT when necessary. PCT will determine which task to run next. PCT will configure timer if it wants to regain control. Address space switch (CR3) may be expensive but should be a relatively rare event.

3) Ecos

Keeps coming up. Interesting embedded OS. Very fine grained configuration system... no, I don't want to support printf("%f", num);

Ecos hardware abstraction layer might be a decent example to follow.