KUT - a Kernel Usable for Tunes bootstrapping

[Basile STARYNKEVITCH]

((Dave Manifold, why should the mailing list not be archived during
the DNS problem?? I feel this is interesting stuff and should be
archived somehow...))

The main current problem with Tunes is that it is not running yet!

this is a followup to my previous post at 21 Jul 1998, 10:22 

I believe the main point of Tunes is that it should be done in a
(reflexive) yet to be defined language. So Tunes should not (and even
cannot) be programmed in C or assembly (because reasoning about itself
will be too hard).

I forgot to say (i.e. I didn't clearly said) that KUT sole purpose is
to permit Tunes bootstrapping. Once Tunes is bootstrapped (ie coded in 
its own language) KUT could be easily forgotten & erased.


Since KUT is aimed to be deleted as soon as Tunes is running, this has
some consequences. The KUT part will be non reflexively written is C &
assembler. It will be (at least partly) overwritten by reflexive Tunes 
code.

I don't wan't to write too much useless code! So I want to keep it
stupid & simple.

I (=Basile) said 

>> KUT runs (only) in 32 bits ring 0 (supervisor) mode, without
>> pagination. 

Ashley Winters asked

> Is that a design choice or have you not gotten around to it? Pagination
> is very useful, even with Tunes. I believe that Tunes should not only
> demand-page load objects, but should also be able to swap ram to disk
> without needing to persistently store full-fledged objects on-disk.

I agree for Tunes, but KUT is intended to make possible Tunes
bootstrap. KUT is not (yet) Tunes - and when it will becomes Tunes,
Tunes will be fully bootstrapping & won't need KUT anymore!

Also, adding pagination & memory management & protection is not a
trivial task, so I would like to avoid it. This would definitely be
doable in Tunes itself.

I (=Basile) also said
>> I don't expect to use TSS (task system segments).

and Ashley Winters replied

> Well, Tunes should take advantage of TSS's when hosting violently
> abusive operating-systems.

I agree, but hosting other OSes is (perhaps) Tunes feature, definitely 
not KUT's.

Again, the main emphasis about KUT is to have a garbageable
(=recyclable) -in the human sense, I mean like disposable stuff such
as Kleenex paper hankerchief [i'm not talking about GC here!]-
system. So I want to use it only for KUT bootstrapping and to get rid
of it as fast as possible.

I (=Basile) proposed 

>>    1) using an available Linux filesystem [...]
>>    2)  writing a sort of KUT filesystem, and write a program (Linux
>>       user mode) which can read,write,& check this filesystem.

The sort of filesystem I was thinking of seems trivial to me
(something like VSTa's bootfs)

Ashley Winters added
>    3) creating a file on a filesystem, and using an index of the
>	disk sectors to be used as your persistent store.

This seems to me a mixture of 1+2 with their added complexity!

I (=Basile) wrote
>> Tunes assembler stuff (the x86 assembler nearly written in Scheme) is
>> IMHO the top priority. 

I actually mean the x86 (or 486 or Pentium) assembler. This is just
having Tunes 0.0.35 (see http://www.tunes.org/)
Tunes/src/LLL/i386/asmx86/ running!

I (=Basile) wrote

>> The KUT kernel should probably contain a bytecode interpreted tuned
>> for Scheme (or Tunes first langage). I think that a bytecode
>> interperter is easier to write than anything else. So we need a
>> cross-compiler to produce the first bytecode programs.

Ashley Winters asked

> Hmm... what would be bytecoded? Shouldn't we be starting Tunes off with
> compiled machine-code? 

I strongly feel (especially for Intel x86 Instruction Set which is
highly non orthogonal) that writing Tunes's initial compiler (to
machine code) is too difficult to be done in machine code or
assembler.

Again, KUT is not Tunes. It is made to make Tunes happen.

The big difficulty (and challenge) about Tunes is that it has a
different language than other OSes. Tunes won't be programmable in C
or C++ or Java! This is a big difference beetwenn free Unixes (Linux,
*BSD) or variants like VSTa or Tinos -which all rely on an *existing*
good enough gcc compiler. Writing Tunes is more like writing Unix in
the 1970s when Unix and C didn't exist yet!

So the main point it to have KUT

* be able to communicate with Tunes programmer -this means screen -code
already written- and keyboard.

* be able to deal with long term storage. This means disk driver (&
some kind of tiny filesystem).

The Tunes programmer will have very little confort to program
Tunes. This means something like edlin editor, not emacs!


Maneesh Yadav wrote

> [...] while you guys have been talking I've been working on a 386
> exokernel..it boots initalizes timers has the logic for
> multiprocessing (I still have to get an SMP system to get the actualy
> code tested...), HD driver running and I will have a FAT system up and
> running soon... I realize I haven't been very active on the mailing
> list it's just that I felt I couldn't contribute...if you guys are
> interested in using this as a base lemme know...what's with all the
> hardware req's?...we don't even know what TUNES looks like running,
> yet.  If you want a bit of a write up again tell me and I will post.

I'm interested by any code!

I think that KUT should be small because

1) it is disposable -run once in principle- cod

2) it would be easier to replace by Tunes

3) lack of features in KUT is an important psychological momentum (for 
us humans) to implement features in Tunes.


The other way to go would be to use the cumfort of an existing OS (eg
Linux) to progressively go to Tunes. But this seems to have failed!  I
believe that the main reason is human programmer psychology!

I feel guilty to have taken so much time to answer, I should devote my 
spare time (I'm Tunes-ing only at home!) to KUT coding!

Again, thanks for the comments!
--

Basile STARYNKEVITCH - 8 rue de la Faiencerie, 92340 BOURG LA REINE (France)
tel 01.46.65.45.53. mél = basile point starynkevitch at wanadoo point fr
boulot=work= basile point starynkevitch at cea point fr