Re: [alliance-iosk] IOSK LM

[vhandel@chem.vu.nl (Ramon van Handel)]

>> I've been looking at the LM (not in great detail, though), Stefano, and I
>> like it (haven't tested it out yet, I'll do that tonight.)
>
>Nice thing to hear.

Sure :)

>We have to agree in which way get resources exactly
>(formally speaking, I can't use CKresourceAlloc, since this function does not
>reside on CK).

No, it's in the CK access library, formally part of the KL but for now
under the CK tree (see CK/lib/architecture/I80X86/syscalls.c).  The
function starts with 'CK' because its implementation is in the CK, though
the actual function CKresourceAlloc() is really the stub, not the function
itself.  You can use CKresourceAlloc(), that's what it's for.

>It's small, and this is intentional (I want to demonstrate that the overhead of
>a dynamic-approach like mine LMs, where only needed things are necessary, is
>*much* better than a standard one). Also, after LMerror is in place, will
>demonstrate how powerful will be error handling.

LMerror isn't documented in your IOSK LM spec... I don't see it in the code
either.  If this isn't implemented yet, ignore my problems in the other
message.

>Remember to answer my previous questions after you test on your PC. It's very
>important that we work out all problems in this first LM, because I want to
>have it fully functional ASAP.

I'll test it tonight, and tease out any bugs I can find.

>> In your Todo list, you mention that you need to write a dynlinker.  This is
>> of course important, but as long as it's on linux we might as well use
>> linux's dynamic linker.
>
>Yes, we could, and I have already written some stuff with dlsym/dlopen/dlclose.
>But it is interesting for me this stuff...

It is VERY interesting, I like it too :).  But one must place priorities
somewhere... ;)

>Question: under CK tree there is ELF.

Do you mean the documentation ?  You can move that.

>Well, from a formal point of view, ELF
>loader should be outside CK,

Not only from a logical point of view.  The CK has nothing to do with ELF.
elf.h is in the main include dir.  The only module that currently has
perliminary ELF support coded is the ABL (ABL/elf.c).

>since it is logically external to the CK
>environment.

>It is a resource used by CK,

Not as far as I know...

>but not pertinent to CK. Also, the LM
>loader will use it also.....where we move that? It's something that AK will
>use, so using your chart is an SL (stands for System Library, isn't it?).

What are you talking about ?  There is not ELF *code* in the CK dir, only
documentation.  The dynamic loader belongs in the KL, not in the SL.

>> What I feel is more important is that you actually
>> make the LM be usable through the IOSK...  perhaps you should work on that
>> first ?  After all, that IS the point of an LM...
>
>This is my exact schedule:
>
>-Add LMerror
>-Modify ioperm (in which way Ramon?)

Same way as the demotasks use it.

>-Add EPP code, so I can hopefully use it really on my PC
>-Modify IOSK code so that will use as default configuration the parallel LM,
>and statically link it to IOSK
>-Start to include queueing code that reside on my HD
>-Use queues to fetch data to parallel LM
>-Include dynalink code
>
>Maybe another LM will be coded, for keyboard handling for instance. It is more
>or less easy to do, so it's not time consuming and will be useful.

... but hard to test on linux... you can't really surpass the linux
terminal code.  You're better off writing LMs for modules that you can turn
off in linux... until the CK can support the IOSK.

Ramon



---
Ramon van Handel   <vhandel@chem.vu.nl>
Chemistry Student, OS Programmer and all-round Weirdo
The ant has made himself illustrious / Through constant industry industrious.
So what? Would you be calm and placid / If you were full of formic acid?
(Ogden Nash)


-
Alliance-IOSK:	http://iosk.allos.org/
Archive:	http://humbolt.nl.linux.org/lists/