a Kernel Usable for Tunes - ideas, questions, and code...
Tue, 21 Jul 1998 21:49:05 -0400
OK, I was lost a long time ago when dave started to talk about all that meta
lambada calculus stuff... I am actually very interested in formal theory but I was
begining get the feeling of way too much abstractness..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
Basile STARYNKEVITCH wrote:
> Hello All,
> ((I posted a message from home <email@example.com> but
> apparently something went wrong, probably on my home Linux PC!!))
> you will find a first pre-alpha (it compiles & links but doesn't run)
> Kernel Usable for Tunes or kut.
> I'm waiting for comments
> -- file KUT/doc.txt
> rcsid $Id: doc.txt,v 0.1 1998/07/19 20:26:31 basile Exp $
> Some ideas regarding KUT (Kernel Usable for Tunes) - I maybe should
> have called it TUK for Tunes Kernel
> (Several ideas are actually from Faré <firstname.lastname@example.org> which whom I meet)
> overall goal:
> make a self-hoisted bootable system, runnable on ordinary ix86/PC, to
> permit TUNES development. Target platform has at least 32Mb RAM (cheap
> today!), an IDE/ATAPI disk (with at least 200Mb free in a dedidacted
> KUT partition), an SVGA screen (and runs Linux!)
> This system is aimed exclusively towards Tunes developpers, not
> towards ordinary users.
> KUT is developped on a Linux platform. The boot loader is GRUB
> BIOS (or Lilo or other loader) loads GRUB which switch into 32 bit
> mode and loads KUT.
> KUT runs (only) in 32 bits ring 0 (supervisor) mode, without
> pagination. I don't expect to use TSS (task system segments). In a
> certain way, KUT is less than a plain 32 bits DOS.
> * two important issues:
> A) how to communicate with Linux? I assume I have only one PC (and I
> don't want to run Tunes under or with Linux, although this is
> debatable). [[not every TUNES developper can afford 2 PCs]]
> essentially, this means sharing some disk stuff with both Linux &
> I'm not really decided between 2 alternatives:
> 1) using an available Linux filesystem, and code it into
> KUT. ext2fs is way too complex for such a task. I might consider
> Minix. A variant could be coding a KUT specific filesystem
> module loadable by a recent (Linux2.0.35 ou 2.1.108) kernel.
> 2) writing a sort of KUT filesystem, and write a program (Linux
> user mode) which can read,write,& check this filesystem.
> I probably prefer the 2nd way. Key idea might be writing a disk
> fragment allocator. a disk fragment is 1 to 64 consecutive disk
> sectors [512bytes each]. Essentially, this means writing a disk
> sector garbage collector. Perhaps almost no file name or directories
> (maybe only one root fixed length directory is enough). But files
> might contain other file pointers. Essentially, do for the disk what
> a simple allocator+garbage collector do for memory. So a file is a
> disk objects, made of other file pointers and plain data.
> B) how to program KUT. The main goal is to have KUT very rapidly self
> hoisted, and able to program TUNES. I think that I have to define a
> specific Scheme dialect (perhaps with a very different
> syntax). Basically, I mean a simple Scheme (eg like SIOD) with
> * some very basic module system
> * no macros
> * almost no I/O (no files) - only keyboard & disk.
> Tunes assembler stuff (the c86 assembler nearly written in Scheme) is
> IMHO the top priority. Then writing the core memory managemetn in
> Tunes assembly+ Scheme and writing a kind of editor/debugger (in Scheme).
> KUT should handle interrupts, and have low level keyboard & disk
> drivers (no netwxork yet).
> BIOS should not be used. Too difficult in 32 bits mode!
> keyboard driver should
> have a non hand-crafted keyboard map. [[keyboard map is a Linux
> keyboard map, compiled into the kernel. Not everyone have a US
> keyboard. I have a French Latin1 azertyuiop (not Qwerty) keyboard.]]
> translate raw keyboard events into sort of keysyms
> define some magic keys for low level debugging...
> disk driver should
> read IDE disk (no SCSI).
> handle a primary partition, and find a KUT partition in it.
> be able to read non KUT (eg DOS or Linux) partitions but don't write
> in them.
> 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.
> I need a lot of hints, advices, and encouragments to help me.
> july 19, 1998
> 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
> N.B. Any opinions expressed here are onely mine, and not of my organization.
> N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
> Basile STARYNKEVITCH ---- Commissariat à l Energie Atomique
> DRN/DMT/SYSCO * CEA/Saclay bat.460 * 91191 GIF/YVETTE CEDEX * France
> fax: (33) 1,69.08.96.96; phone: 1,69.08.40.66; home: 1,188.8.131.52
> email: Basile point Starynkevitch at cea point fr
> I speak french, english, russian. Je parle français, anglais, russe.
> Pursuant to USC 47, there is a $500 per incident charge for each
> and every piece of Unsolicited Commercial Email (UCE) sent to this or
> any of my other addresses. Sending UCE's to any of my addresses
> implies general acceptance of these terms.