From movitz-devel at common-lisp.net Thu Nov 4 23:54:53 2004 From: movitz-devel at common-lisp.net (Chasity Jensen) Date: Fri, 05 Nov 2004 02:54:53 +0300 Subject: [movitz-devel] attestation Message-ID: <4817389895001.37833@movitz-devel@common-lisp.net> Movitz-devel,: valiumXanaxCialis and_more Get Hydrocodone, or Soma.~ 2 of the best pain killers out! please LQQk* http://kucmalxpo.conscious2horsepower.info/b12m -- dryden dextrous degum dough marianne cardboard dirac labradorite lunchtime hog bovine umbilicus hereabout imperious onomatopoeia brookline blouse macdonald southwest satiric cupid thanksgiving yoder orange prophecy archetype gamecock louisa . From mulix at mulix.org Sun Nov 21 13:03:29 2004 From: mulix at mulix.org (Muli Ben-Yehuda) Date: Sun, 21 Nov 2004 15:03:29 +0200 Subject: [movitz-devel] implementing the process abstraction in movitz Message-ID: <20041121130329.GK8461@granada.merseine.nu> Hello, First of all, I think movitz is very cool. I've been thinking for a long time of writing a lisp OS, and was very happy to stumble up on movitz. I am now considering implementing the process abstraction (namely, fork(), wait(), some variant of exec(), and context switching) in movitz, as an OS project, along the lines of the attached proposal. Any thoughts on the right way to do this, and what, if anything, already exists will be appreciated. Pointers to the source will be happily accepted. Cheers, Muli Design and implementation of the process abstraction in a lisp based OS ----------------------------------------------------------------------- movitz[1] is an experimental operating system running on commodity x86 hardware. Unlike traditional operating systems which are written in the statically typed C or C++ programming languages ("portable assembly"), movitz is written in the high level, dynamically typed, Common Lisp[2] programming language. Lisp based operating systems have existed before, e.g. the Symbolics Lisp Machine[3]. However, they ran on specially crafted hardware which was tailored for running lisp code. movitz, on the other hand, runs on standard personal computers. For this seminar, we propose to design and implement the process abstraction in the movitz operating system. Currently, movitz boots and drops the user into a kernel level Read-Eval-Print loop (Common Lisp interpreter). We propose to design and implement the fork(), wait() and exec() operations in movitz, as well as context switching. The design and implementation will then be contrasted fork(), wait() and exec() in a traditional operating system, such as the Linux[4] kernel. We will show that by virtue of being written in Common Lisp, a dynamic language, implementing the process abstraction in movitz is easier and better, for some definition of better. Better might mean for example that the implementation is faster, simpler to write, less error prone, easier to modify, or any other objective criteria. [1] http://common-lisp.net/project/movitz/ [2] http://www.lisp.org/alu/res-lisp#common-lisp [3] http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/symbolics.html [4] http://www.kernel.org/ -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ffjeld at common-lisp.net Sun Nov 21 17:58:20 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Sun, 21 Nov 2004 18:58:20 +0100 Subject: [movitz-devel] Re: implementing the process abstraction in movitz References: <20041121130329.GK8461@granada.merseine.nu> Message-ID: <2hzn1bkrsz.fsf@vserver.cs.uit.no> Muli Ben-Yehuda writes: > First of all, I think movitz is very cool. I've been thinking for a > long time of writing a lisp OS, and was very happy to stumble up on > movitz. I am now considering implementing the process abstraction > (namely, fork(), wait(), some variant of exec(), and context > switching) in movitz, as an OS project, along the lines of the > attached proposal. [..] Hi (again), sounds like an interesting project to me. I think the first thing you need to make clear for yourself is the exact nature of the fork() etc. That is, the normal unix fork() sets up a new address-space etc and in principle shares nothing with anyone else (except perhaps by copy-on-write semantics) and communicates purely through system-calls (in various forms). Is this what you want to do? In theory you could quite literally implement unix fork() this way, in the sense that if you set up an address-space, exception handlers, an elf-loader etc and emulate e.g. the linux system-calls, then you should be able to run linux processes this way (although I suppose it'll be a substantial job, reimplementing the linux kernel..) Or something more lispy with a single-address-space system where you share e.g. the common-lisp package (with symbols, functions, etc) between the processes? Btw. I expect to implement some lightweight threading stuff in Movitz soon, I expect to need it for the thesis I'm working on. -- Frode Vatvedt Fjeld From sRp at srparish.net Sun Nov 21 19:42:21 2004 From: sRp at srparish.net (Scott Parish) Date: Sun, 21 Nov 2004 19:42:21 +0000 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <2hzn1bkrsz.fsf@vserver.cs.uit.no> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> Message-ID: <20041121194221.GQ6870@srparish.net> On Sun, Nov 21, 2004 at 06:58:20PM +0100, Frode Vatvedt Fjeld wrote: > Or something more lispy with a single-address-space system where you > share e.g. the common-lisp package (with symbols, functions, etc) > between the processes? I haven't thought into this very far, but a capability based operating system (like eros) based on lisp might make a very interesting mix. sRp -- Scott Parish http://srparish.net/ From mulix at mulix.org Tue Nov 23 12:17:54 2004 From: mulix at mulix.org (Muli Ben-Yehuda) Date: Tue, 23 Nov 2004 14:17:54 +0200 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <2hzn1bkrsz.fsf@vserver.cs.uit.no> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> Message-ID: <20041123121754.GJ24710@granada.merseine.nu> On Sun, Nov 21, 2004 at 06:58:20PM +0100, Frode Vatvedt Fjeld wrote: > Muli Ben-Yehuda writes: > > > First of all, I think movitz is very cool. I've been thinking for a > > long time of writing a lisp OS, and was very happy to stumble up on > > movitz. I am now considering implementing the process abstraction > > (namely, fork(), wait(), some variant of exec(), and context > > switching) in movitz, as an OS project, along the lines of the > > attached proposal. [..] > > Hi (again), sounds like an interesting project to me. I think the > first thing you need to make clear for yourself is the exact nature of > the fork() etc. That is, the normal unix fork() sets up a new > address-space etc and in principle shares nothing with anyone else > (except perhaps by copy-on-write semantics) and communicates purely > through system-calls (in various forms). Is this what you want to > do? The ultimate term goal is a full POSIX / Linux emulation layer for movitz that would allow you to run unmodified Linux binaries. Since this is a very big undertaking, my short term goals are the following basic operations - fork - set up a new context. Open questions are whether it supports seperate address spaces (process or threads?) and whether it supports memory protections (user context vs. kernel context). I haven't decided yet, I would prefer processes to threads and user contexts to kernel contexts, but I don't have a good feeling of the scope of the effort involved yet. > Btw. I expect to implement some lightweight threading stuff in Movitz > soon, I expect to need it for the thesis I'm working on. Could you elaborate on what you have in mind? I wouldn't want to duplicate effort. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ffjeld at common-lisp.net Tue Nov 23 13:39:38 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 23 Nov 2004 14:39:38 +0100 Subject: [movitz-devel] Re: implementing the process abstraction in movitz References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> Message-ID: <2hmzx8y99h.fsf@vserver.cs.uit.no> Muli Ben-Yehuda writes: > The ultimate term goal is a full POSIX / Linux emulation layer for > movitz that would allow you to run unmodified Linux binaries. Since > this is a very big undertaking, my short term goals are the > following basic operations > > - fork - set up a new context. Open questions are whether it supports > seperate address spaces (process or threads?) and whether it supports > memory protections (user context vs. kernel context). I think if your goal really is linux emulation, then you really need to set up an address-space with paging etc. Make a (defclass linux-process ..) that plays abuot the same role as the linux "proc" structure (or something like that, I don't really remember its name..), and your fork must essentially do the same as linux fork does. Although I'd model it in terms of some initialization method on linux-process, where fork initializes an instance as a copy of another process. I'd start off by making some accessors to the paging hardware, and build on that. > Could you elaborate on what you have in mind? I wouldn't want to > duplicate effort. I don't think you need to worry much about that. What I have in mind is just some simple form of threads running in more or less the same context as everything else. Btw I recently wrote some basic mechanism for interfacing the PCI bios32 thingy. If anyone here has any experience with this stuff, such as what's the overall way this is to be used (firstly for device discovery), I'd like to hear from you. I'll check in x86-pc/pci.lisp asap. -- Frode Vatvedt Fjeld From pjb at informatimago.com Tue Nov 23 13:58:09 2004 From: pjb at informatimago.com (Pascal J.Bourguignon) Date: Tue, 23 Nov 2004 14:58:09 +0100 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <2hmzx8y99h.fsf@vserver.cs.uit.no> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> <2hmzx8y99h.fsf@vserver.cs.uit.no> Message-ID: <16803.16881.913574.811505@thalassa.informatimago.com> Frode Vatvedt Fjeld writes: > Muli Ben-Yehuda writes: > > > The ultimate term goal is a full POSIX / Linux emulation layer for > > movitz that would allow you to run unmodified Linux binaries. Since > > this is a very big undertaking, my short term goals are the > > following basic operations > > > > - fork - set up a new context. Open questions are whether it supports > > seperate address spaces (process or threads?) and whether it supports > > memory protections (user context vs. kernel context). > > I think if your goal really is linux emulation, then you really need > to set up an address-space with paging etc. Make a (defclass > linux-process ..) that plays abuot the same role as the linux "proc" > structure (or something like that, I don't really remember its > name..), and your fork must essentially do the same as linux fork > does. Although I'd model it in terms of some initialization method on > linux-process, where fork initializes an instance as a copy of another > process. I'd start off by making some accessors to the paging > hardware, and build on that. It seems to me that if the goal is Linux, it would be much better to approach it from the virtual machine point of view: provide a hardware abstraction layer, and adapt UML, User-Mode-Linux (or Linux using User-Mode-linux as a model) to your hardware abstraction virtual machine. At most, you'll have to write a couple of Linux drivers. (Some inspiration could be got from MOL, Macintosh-On-Linux too). Then it'll be possible to port any OS to this Movitz Virtual Machine. This could simplify the driver problem too, since the virtualizer could just arbitrate (some) hardware access to the guest OSes. We'd need drivers only for the hardware used directly by Movitz. -- __Pascal Bourguignon__ http://www.informatimago.com/ The world will now reboot; don't bother saving your artefacts. From sRp at srparish.net Tue Nov 23 14:51:10 2004 From: sRp at srparish.net (Scott Parish) Date: Tue, 23 Nov 2004 14:51:10 +0000 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <16803.16881.913574.811505@thalassa.informatimago.com> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> <2hmzx8y99h.fsf@vserver.cs.uit.no> <16803.16881.913574.811505@thalassa.informatimago.com> Message-ID: <20041123145109.GF11379@srparish.net> On Tue, Nov 23, 2004 at 02:58:09PM +0100, Pascal J. Bourguignon wrote: > It seems to me that if the goal is Linux, it would be much better to > approach it from the virtual machine point of view: provide a hardware > abstraction layer, and adapt UML, User-Mode-Linux (or Linux using > User-Mode-linux as a model) to your hardware abstraction virtual > machine. At most, you'll have to write a couple of Linux > drivers. (Some inspiration could be got from MOL, Macintosh-On-Linux > too). > > Then it'll be possible to port any OS to this Movitz Virtual Machine. > > This could simplify the driver problem too, since the virtualizer > could just arbitrate (some) hardware access to the guest OSes. We'd > need drivers only for the hardware used directly by Movitz. Basically, rewrite Xen (http://www.cl.cam.ac.uk/Research/SRG/netos/xen/). sRp -- Scott Parish http://srparish.net/ From ffjeld at common-lisp.net Tue Nov 23 15:18:35 2004 From: ffjeld at common-lisp.net (Frode Vatvedt Fjeld) Date: Tue, 23 Nov 2004 16:18:35 +0100 Subject: [movitz-devel] Re: implementing the process abstraction in movitz References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> <2hmzx8y99h.fsf@vserver.cs.uit.no> <16803.16881.913574.811505@thalassa.informatimago.com> Message-ID: <2h4qjgy4ok.fsf@vserver.cs.uit.no> Pascal J.Bourguignon writes: > It seems to me that if the goal is Linux, it would be much better to > approach it from the virtual machine point of view: provide a > hardware abstraction layer, and adapt UML, User-Mode-Linux (or Linux > using User-Mode-linux as a model) to your hardware abstraction > virtual machine. This is quite possible. However, I think the goals "running linux" and "running linux processes" are quite different. It's a bit unclear to me what the value of lisp would be in providing a VM that more or less runs a complete linux (etc) kernel: essentially the entire static blob remains. In the latter case (the running linux processes goal), only individual processes remain as blobs, and they at least are defined somewhat properly in terms of address-space and system-calls etc. To me, the interesting thing is to remove as much as possible of the tradidional unix-style static blobs and have interactive, introspective etc lisp instead. But of course others will have different goals and interests. -- Frode Vatvedt Fjeld From pjb at informatimago.com Tue Nov 23 15:43:05 2004 From: pjb at informatimago.com (Pascal J.Bourguignon) Date: Tue, 23 Nov 2004 16:43:05 +0100 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <2h4qjgy4ok.fsf@vserver.cs.uit.no> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> <2hmzx8y99h.fsf@vserver.cs.uit.no> <16803.16881.913574.811505@thalassa.informatimago.com> <2h4qjgy4ok.fsf@vserver.cs.uit.no> Message-ID: <16803.23177.869644.687789@thalassa.informatimago.com> Frode Vatvedt Fjeld writes: > Pascal J.Bourguignon writes: > > > It seems to me that if the goal is Linux, it would be much better to > > approach it from the virtual machine point of view: provide a > > hardware abstraction layer, and adapt UML, User-Mode-Linux (or Linux > > using User-Mode-linux as a model) to your hardware abstraction > > virtual machine. > > This is quite possible. However, I think the goals "running linux" and > "running linux processes" are quite different. It's a bit unclear to > me what the value of lisp would be in providing a VM that more or less > runs a complete linux (etc) kernel: essentially the entire static blob > remains. In the latter case (the running linux processes goal), only > individual processes remain as blobs, and they at least are defined > somewhat properly in terms of address-space and system-calls etc. To > me, the interesting thing is to remove as much as possible of the > tradidional unix-style static blobs and have interactive, > introspective etc lisp instead. But of course others will have > different goals and interests. Indeed, it all depends on the purpose. For example, on Movitz, do we need to run emacs/linux unchanged, or would we prefer to run Hemlock in a Common-Lisp OS enviroment? Do we need to run Apache/linux, or do we want to run PortableAlegroServe? At the kernel level, once you implement the unix syscall API, you've essentially re-implemented yet another unix kernel, be it monolithically, or in guise of microkernel or exokernel, like minix or bsd/mach. Would a mere unix kernel implemented in lisp be a better OS? I doubt it: it would just be another unix kernel. On the other hand, once we have a virtualizer, we can explore new OS avenues, benefiting the fluidity of lisp, while being able to run in another virtual machine the legacy OS(es) we need to get the needed legacy programs running. (In addition, judging by the size of the source of xen, a virtualizer is much smaller than a unix kernel...) -- __Pascal Bourguignon__ http://www.informatimago.com/ The world will now reboot; don't bother saving your artefacts. From mulix at mulix.org Wed Nov 24 20:23:22 2004 From: mulix at mulix.org (Muli Ben-Yehuda) Date: Wed, 24 Nov 2004 22:23:22 +0200 Subject: [movitz-devel] Re: implementing the process abstraction in movitz In-Reply-To: <2hmzx8y99h.fsf@vserver.cs.uit.no> References: <20041121130329.GK8461@granada.merseine.nu> <2hzn1bkrsz.fsf@vserver.cs.uit.no> <20041123121754.GJ24710@granada.merseine.nu> <2hmzx8y99h.fsf@vserver.cs.uit.no> Message-ID: <20041124202322.GH24190@granada.merseine.nu> On Tue, Nov 23, 2004 at 02:39:38PM +0100, Frode Vatvedt Fjeld wrote: > I think if your goal really is linux emulation, then you really need > to set up an address-space with paging etc. Make a (defclass > linux-process ..) that plays abuot the same role as the linux "proc" > structure (or something like that, I don't really remember its > name..), struct task_struct > and your fork must essentially do the same as linux fork > does. Although I'd model it in terms of some initialization method on > linux-process, where fork initializes an instance as a copy of another > process. I'd start off by making some accessors to the paging > hardware, and build on that. sounds like the way to go, regardless of how I end up implementing it. > > Could you elaborate on what you have in mind? I wouldn't want to > > duplicate effort. > > I don't think you need to worry much about that. What I have in mind > is just some simple form of threads running in more or less the same > context as everything else. Ok, I'll keep my eyes open on the commits mailing list. Thanks. Cheers, Muli -- Muli Ben-Yehuda http://www.mulix.org | http://mulix.livejournal.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: