headers
Ram Vedam | 13 Jun 2009 00:11
Picon

Threading Model and Parallelization Model inside Movitz

I was wondering if the threading.lisp file inside the losp/ directory represents base threading model that Movitz is planning on supporting... Also, is there an overarching design already in the works or is this an area that still needs to be worked on?

Ram

<div><p>I was wondering if the threading.lisp file inside the losp/ directory represents base threading model that Movitz is planning on supporting... Also, is there an overarching design already in the works or is this an area that still needs to be worked on?<br><br>Ram<br></p></div>
Permalink | Reply |
headers
Frode V. Fjeld | 13 Jun 2009 01:20
Picon
Picon
Favicon

Re: Threading Model and Parallelization Model inside Movitz

Ram Vedam <rvedam <at> gmail.com> writes:

> I was wondering if the threading.lisp file inside the losp/
> directory represents base threading model that Movitz is planning on
> supporting... Also, is there an overarching design already in the
> works or is this an area that still needs to be worked on?

An overarching design (in terms of I/O, processes etc.) needs to be worked on.

--

-- 
Frode V. Fjeld
Permalink | Reply |
headers
Brian Makin | 13 Jun 2009 02:40
Picon

OS decisions

Some architecture questions... some of which may not have been decided  
yet.

Do we want to support 32 and 64 bit?
SMP?
Will there be virtual memory?
Memory protection?
What kind of file system? or use an existing one?
Will it have a console or be gui driven?
Permalink | Reply |
headers
Frode V. Fjeld | 15 Jun 2009 12:26
Picon
Picon
Favicon

Re: OS decisions

Brian Makin <merimus <at> gmail.com> writes:

> Some architecture questions... some of which may not have been
> decided yet.
>
> Do we want to support 32 and 64 bit?

I think 64-bit is definitely the way to go, because the increased word
size is beneficial to lisp, and the increased address space (same
thing obviously) is beneficial to OS hacking.

> SMP?

Of course.

> Will there be virtual memory?

I think "virtual memory" is these more-or-less separate things:

  1. Swapping: A way to increase the memory size by means of secondary
     storage.

  2. Circumventing the problems that come from the (too) limited
     address space.

  3. Aid the loading of static (non-position-independent) code. By
     offering the exact same (virtual) address space to each program,
     addresses can be hard-coded into the (compiled) program's file
     image, making loading/linking a no-op.

Some thoughts on each poing wrt. Movitz:

  1. Primary storage (DRAM) is dirt cheap now.
  2. 64-bit more or less makes this a non-issue.
  3. This is not so interesting for dynamic systems.

> Memory protection?
> What kind of file system? or use an existing one?
> Will it have a console or be gui driven?

In my personal vision for Movitz, these design questions belong to the
architectural layer above Movitz. That is, I've tried so far to make
everything agnostic to these things, allowing for a big solution space
for systems built atop Movitz. So for example, there is no explicit
SMP support, but everything is designed so that introducing SMP should
not break anything (there's no issues like "the big central
interpreter lock" or somesuch). This is to explain why I've kept my
focus somewhat low-level, and haven't built much higher-level stuff
that would probably have attracted more attention (and perhaps code
contributions.. I guess this is part of the Worse is Better argument:
start with the shiny veneer and the hull will get filled much more
quickly than if you start with a boring core.. :)

--

-- 
Frode V. Fjeld
Permalink | Reply |
headers
Shawn Betts | 13 Jun 2009 23:35
Picon

Re: OS decisions

On Fri, Jun 12, 2009 at 5:40 PM, Brian Makin<merimus <at> gmail.com> wrote:
> Some architecture questions... some of which may not have been decided
> yet.
>
> Do we want to support 32 and 64 bit?

I believe Frode was working on a 64bit port.

> SMP?

Sure, why not?

> Will there be virtual memory?

You sorta have to if you want to access all the computer's memory don't you?

> Memory protection?

In many ways lisp doesn't need memory protection since you don't
create pointers out of thin air like in C. That said, it could be
useful for security purposes if movitz was a multiuser system.

> What kind of file system? or use an existing one?

I think an existing one would be fine.

> Will it have a console or be gui driven?

Both of course! :)

-Shawn
Permalink | Reply |
headers
Samium Gromoff | 14 Jun 2009 11:51
Picon

Re: OS decisions

From: Shawn Betts <sabetts <at> gmail.com>
>> Memory protection?
> 
> In many ways lisp doesn't need memory protection since you don't
> create pointers out of thin air like in C. That said, it could be
> useful for security purposes if movitz was a multiuser system.

The thing is, it's impossible to prevent the user from accessing
arbitrary functions in CL -- and things like SB-SYS:SAP-REF-*
precisely allow arbitrary pointer dereference.

Another issue is unsafely compiled code with violated declarations.
This could literally explode an unprotected memory system.

> -Shawn

regards, Samium Gromoff
Permalink | Reply |
headers
Brian Makin | 14 Jun 2009 01:30
Picon

Re: OS decisions


On Jun 13, 2009, at 5:35 PM, Shawn Betts wrote:

> On Fri, Jun 12, 2009 at 5:40 PM, Brian Makin<merimus <at> gmail.com> wrote:
>> Some architecture questions... some of which may not have been  
>> decided
>> yet.
>>
>> Do we want to support 32 and 64 bit?
>
> I believe Frode was working on a 64bit port.
>
>> SMP?
>
> Sure, why not?
>
>> Will there be virtual memory?
>
> You sorta have to if you want to access all the computer's memory  
> don't you?
>

More of a question of paging.  You could decide that ram sizes are  
large enough that we don't need it...

>> Memory protection?
>
> In many ways lisp doesn't need memory protection since you don't
> create pointers out of thin air like in C. That said, it could be
> useful for security purposes if movitz was a multiuser system.
>

Protection between user processes probably aren't as important.  In a  
multiuser system you would still want projection between user and  
kernel space however.

>> What kind of file system? or use an existing one?
>
> I think an existing one would be fine.
>
>> Will it have a console or be gui driven?
>
> Both of course! :)
>
> -Shawn
>
> _______________________________________________
> movitz-devel site list
> movitz-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
Permalink | Reply |
headers
Shawn Betts | 14 Jun 2009 03:41
Picon

Re: OS decisions

> Protection between user processes probably aren't as important.  In a
> multiuser system you would still want projection between user and kernel
> space however.

What is user and kernel space in a lisp OS and why do you need protection?

-Shawn
Permalink | Reply |
headers
Brian Makin | 14 Jun 2009 03:58
Picon

Re: OS decisions


Well, if you don't have some protection between a user and the base  
system then any user would be able to do nasty things to other people  
on the system.

Grab their passwords, kill their processes, intercept their network  
traffic etc...

Genera for example was single user only.  On top of that it didn't  
even try to protect the user from themselves.  If you overwrote the  
scheduler with minesweeper... so be it.

You could make a multiuser system without that sort of protection but  
then a hostile (or careless) user could cause havoc.

On Jun 13, 2009, at 9:41 PM, Shawn Betts wrote:

>> Protection between user processes probably aren't as important.  In a
>> multiuser system you would still want projection between user and  
>> kernel
>> space however.
>
> What is user and kernel space in a lisp OS and why do you need  
> protection?
>
> -Shawn
>
> _______________________________________________
> movitz-devel site list
> movitz-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
Permalink | Reply |
headers
Shawn Betts | 14 Jun 2009 04:12
Picon

Re: OS decisions

On Sat, Jun 13, 2009 at 6:58 PM, Brian Makin<merimus <at> gmail.com> wrote:
>
> Well, if you don't have some protection between a user and the base system
> then any user would be able to do nasty things to other people on the
> system.
>
> Grab their passwords, kill their processes, intercept their network traffic
> etc...
>
> Genera for example was single user only.  On top of that it didn't even try
> to protect the user from themselves.  If you overwrote the scheduler with
> minesweeper... so be it.

But how do you define kernel and user space? If I get "access" to the
scheduler and make a tweak so it calls a special function I just
wrote, how would that function be tagged as being crucial to the
system? Would you be able to have a process-wait-function if you
seperated "kernel" and "user" spaces?

> You could make a multiuser system without that sort of protection but then a
> hostile (or careless) user could cause havoc.

I don't think anyone is questioning that. I'm trying to imagine how it
would work. How would you seperate all the objects floating around in
memory?
Permalink | Reply |
headers
Brian Makin | 14 Jun 2009 04:40
Picon

Re: OS decisions


Well, we could certainly put some functions in a protected memory space.
It would require some system support so that you couldn't simply  
override the func.

Perhaps a better way would be like this.
A particular context (looks like the lisp term would be environment)  
could have permissions.

The read/write/execute model would probably work.
You could execute a function, read the source, or write(change) the  
function.

Thinking more on this... it is an interesting question.

Lets use a function
movitz:network:tx_packet

I would imagine that an unprivileged user would not be able to  
redefine that function within that context. ie: change the systems  
tx_packet function.  When the symbol is looked up it's permission is  
gotten from the environment in which it is defined.

Does the concept of having permissions on an environment even make  
sense?

On Jun 13, 2009, at 10:12 PM, Shawn Betts wrote:

> On Sat, Jun 13, 2009 at 6:58 PM, Brian Makin<merimus <at> gmail.com> wrote:
>>
>> Well, if you don't have some protection between a user and the base  
>> system
>> then any user would be able to do nasty things to other people on the
>> system.
>>
>> Grab their passwords, kill their processes, intercept their network  
>> traffic
>> etc...
>>
>> Genera for example was single user only.  On top of that it didn't  
>> even try
>> to protect the user from themselves.  If you overwrote the  
>> scheduler with
>> minesweeper... so be it.
>
> But how do you define kernel and user space? If I get "access" to the
> scheduler and make a tweak so it calls a special function I just
> wrote, how would that function be tagged as being crucial to the
> system? Would you be able to have a process-wait-function if you
> seperated "kernel" and "user" spaces?
>
>> You could make a multiuser system without that sort of protection  
>> but then a
>> hostile (or careless) user could cause havoc.
>
> I don't think anyone is questioning that. I'm trying to imagine how it
> would work. How would you seperate all the objects floating around in
> memory?
>
> _______________________________________________
> movitz-devel site list
> movitz-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel
Permalink | Reply |
headers
Ram Vedam | 14 Jun 2009 01:57
Picon

Re: OS decisions

Is Movitz or should Movitz be geared towards becoming a multiuser system? I think it would be a good idea... and if that is the eventual goal, then memory protection is a very good idea. Though wouldn't you need memory protection for process isolation to work correctly? Unless I'm missing something here...

Ram

On Sat, Jun 13, 2009 at 6:30 PM, Brian Makin <merimus <at> gmail.com> wrote:

On Jun 13, 2009, at 5:35 PM, Shawn Betts wrote:

> On Fri, Jun 12, 2009 at 5:40 PM, Brian Makin<merimus <at> gmail.com> wrote:
>> Some architecture questions... some of which may not have been
>> decided
>> yet.
>>
>> Do we want to support 32 and 64 bit?
>
> I believe Frode was working on a 64bit port.
>
>> SMP?
>
> Sure, why not?
>
>> Will there be virtual memory?
>
> You sorta have to if you want to access all the computer's memory
> don't you?
>

More of a question of paging.  You could decide that ram sizes are
large enough that we don't need it...

>> Memory protection?
>
> In many ways lisp doesn't need memory protection since you don't
> create pointers out of thin air like in C. That said, it could be
> useful for security purposes if movitz was a multiuser system.
>

Protection between user processes probably aren't as important.  In a
multiuser system you would still want projection between user and
kernel space however.

>> What kind of file system? or use an existing one?
>
> I think an existing one would be fine.
>
>> Will it have a console or be gui driven?
>
> Both of course! :)
>
> -Shawn
>
> _______________________________________________
> movitz-devel site list
> movitz-devel <at> common-lisp.net
> http://common-lisp.net/mailman/listinfo/movitz-devel


_______________________________________________
movitz-devel site list
movitz-devel <at> common-lisp.net
http://common-lisp.net/mailman/listinfo/movitz-devel

<div>
<p>Is Movitz or should Movitz be geared towards becoming a multiuser system? I think it would be a good idea... and if that is the eventual goal, then memory protection is a very good idea. Though wouldn't you need memory protection for process isolation to work correctly? Unless I'm missing something here...<br><br>Ram<br><br></p>
<div class="gmail_quote">On Sat, Jun 13, 2009 at 6:30 PM, Brian Makin <span dir="ltr">&lt;<a href="mailto:merimus <at> gmail.com">merimus <at> gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="im">
<br>
On Jun 13, 2009, at 5:35 PM, Shawn Betts wrote:<br><br>
&gt; On Fri, Jun 12, 2009 at 5:40 PM, Brian Makin&lt;<a href="mailto:merimus <at> gmail.com">merimus <at> gmail.com</a>&gt; wrote:<br>
&gt;&gt; Some architecture questions... some of which may not have been<br>
&gt;&gt; decided<br>
&gt;&gt; yet.<br>
&gt;&gt;<br>
&gt;&gt; Do we want to support 32 and 64 bit?<br>
&gt;<br>
&gt; I believe Frode was working on a 64bit port.<br>
&gt;<br>
&gt;&gt; SMP?<br>
&gt;<br>
&gt; Sure, why not?<br>
&gt;<br>
&gt;&gt; Will there be virtual memory?<br>
&gt;<br>
&gt; You sorta have to if you want to access all the computer's memory<br>
&gt; don't you?<br>
&gt;<br><br>
</div>More of a question of paging. &nbsp;You could decide that ram sizes are<br>
large enough that we don't need it...<br><div class="im">
<br>
&gt;&gt; Memory protection?<br>
&gt;<br>
&gt; In many ways lisp doesn't need memory protection since you don't<br>
&gt; create pointers out of thin air like in C. That said, it could be<br>
&gt; useful for security purposes if movitz was a multiuser system.<br>
&gt;<br><br>
</div>Protection between user processes probably aren't as important. &nbsp;In a<br>
multiuser system you would still want projection between user and<br>
kernel space however.<br><div>
<div></div>
<div class="h5">
<br>
&gt;&gt; What kind of file system? or use an existing one?<br>
&gt;<br>
&gt; I think an existing one would be fine.<br>
&gt;<br>
&gt;&gt; Will it have a console or be gui driven?<br>
&gt;<br>
&gt; Both of course! :)<br>
&gt;<br>
&gt; -Shawn<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; movitz-devel site list<br>
&gt; <a href="mailto:movitz-devel <at> common-lisp.net">movitz-devel <at> common-lisp.net</a><br>
&gt; <a href="http://common-lisp.net/mailman/listinfo/movitz-devel" target="_blank">http://common-lisp.net/mailman/listinfo/movitz-devel</a><br><br><br>
_______________________________________________<br>
movitz-devel site list<br><a href="mailto:movitz-devel <at> common-lisp.net">movitz-devel <at> common-lisp.net</a><br><a href="http://common-lisp.net/mailman/listinfo/movitz-devel" target="_blank">http://common-lisp.net/mailman/listinfo/movitz-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
Permalink | Reply |
headers
Brian Makin | 14 Jun 2009 02:41
Picon

Re: OS decisions


On Jun 13, 2009, at 7:57 PM, Ram Vedam wrote:

> Is Movitz or should Movitz be geared towards becoming a multiuser  
> system? I think it would be a good idea... and if that is the  
> eventual goal, then memory protection is a very good idea. Though  
> wouldn't you need memory protection for process isolation to work  
> correctly? Unless I'm missing something here...

Process isolation isn't quite as important when you can't write into  
random memory locations so easily.
If you have one lisp process running and I have another... how can I  
do something bad to you?
Permalink | Reply |
headers
Frode V. Fjeld | 15 Jun 2009 12:01
Picon
Picon
Favicon

Re: OS decisions

Brian Makin <merimus <at> gmail.com> writes:

> Process isolation isn't quite as important when you can't write into
> random memory locations so easily.  If you have one lisp process
> running and I have another... how can I do something bad to you?

It boils down to what is your design goals, doesn't it? Thinking
historically about this, I believe that memory protection (or even
multi-user systems in general) came about because machines were so
huge and costly that sharing them between people (and even
organizations) was inevitable. But this pattern is very nearly
inverted now, in that each person now has (exclusive) access to
several machines.

That's not to say that hw protection isn't nice to have (and for some
applications even necessary), but remember also that there tends to an
inherent cost in terms of performance, system/code/programming
complexity, and general barriers to information flow.

So perhaps it would be more beneficial to focus on removing the
communication barriers between machines than how to add barriers
inside them? (Not to imply that these are conflicting desing goals,
other than wrt. time and effort.)

--

-- 
Frode V. Fjeld
Permalink | Reply |
headers
Robert Swindells | 14 Jun 2009 02:33
Picon
Picon

Re: OS decisions


Brian Makin wrote:
>On Jun 13, 2009, at 5:35 PM, Shawn Betts wrote:
>> On Fri, Jun 12, 2009 at 5:40 PM, Brian Makin<merimus <at> gmail.com> wrote:
>>> Some architecture questions... some of which may not have been  
>>> decided
>>> yet.
>>>
>>> Do we want to support 32 and 64 bit?
>>
>> I believe Frode was working on a 64bit port.
>>
>>> SMP?
>>
>> Sure, why not?
>>
>>> Will there be virtual memory?
>>
>> You sorta have to if you want to access all the computer's memory  
>> don't you?
>>

>More of a question of paging.  You could decide that ram sizes are  
>large enough that we don't need it...

I think you could leave this until it is needed.

>>> Memory protection?
>>
>> In many ways lisp doesn't need memory protection since you don't
>> create pointers out of thin air like in C. That said, it could be
>> useful for security purposes if movitz was a multiuser system.
>>

>Protection between user processes probably aren't as important.  In a  
>multiuser system you would still want projection between user and  
>kernel space however.

In my view the easiest way to get a multiuser system would be to make
Movitz run virtualized on top of Xen, you then just run one DomU per
user.

>> What kind of file system? or use an existing one?
>
> I think an existing one would be fine.

One option is to port LMFS from the MIT sources to Common Lisp.

Robert Swindells
Permalink | Reply |
headers
Brian Makin | 14 Jun 2009 02:50
Picon

Re: OS decisions


>
>> More of a question of paging.  You could decide that ram sizes are
>> large enough that we don't need it...
>
> I think you could leave this until it is needed.
>
Agreed... but if we eventually want the ability it's better to keep it  
in mind.
>
>
>>> What kind of file system? or use an existing one?
>>
>> I think an existing one would be fine.
>
> One option is to port LMFS from the MIT sources to Common Lisp.
>
> Robert Swindells

Other than versioning LMFS doesn't look too different from modern FS.

I'm just kind of thrashing around trying to find a place I can  
effectively contribute :)
Permalink | Reply |
headers
Robert Swindells | 14 Jun 2009 19:08
Picon
Picon

Re: OS decisions


Brian Makin wrote:
>>>> What kind of file system? or use an existing one?
>>>
>>> I think an existing one would be fine.
>>
>> One option is to port LMFS from the MIT sources to Common Lisp.
>>
>> Robert Swindells

>Other than versioning LMFS doesn't look too different from modern FS.

Except that it is written in Lisp and designed to work in a single
address space.

It won't be as efficent but can probably be made to do something
useful much faster than starting from scratch to copy another
filesystem.

>I'm just kind of thrashing around trying to find a place I can  
>effectively contribute :)

There are plenty of places to contribute. What kind of thing do you
want to work on ? Something at a high or low level ?

High Level:

Pick up code from SBCL or CMUCL for the top level file and io functions.

Do same for Simple Streams to add device-read and device-write, don't
need the helper functions read-octets and write-octets though.

Low Level:

Modern PCs don't use the 8259 interrupt controller, they use the LAPIC
and use ACPI to work out which interrupts are generated by which
device. Someone could start looking at parsing the ACPI tables within
Movitz.

The interrupt handling sequence might benefit from some changes too, I
guess you could install a closure as the handler but it could be
simpler to pass some object as an argument to the handler function.

Robert Swindells
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Permalink | Reply |
headers
Frode V. Fjeld | 15 Jun 2009 11:50
Picon
Picon
Favicon

Re: OS decisions

Robert Swindells <rjs <at> fdy2.demon.co.uk> writes:

> The interrupt handling sequence might benefit from some changes too,
> I guess you could install a closure as the handler but it could be
> simpler to pass some object as an argument to the handler function.

As of now there's two mechanisms for setting up interrupt
handlers. The lower-level one is pretty much exactly the setting of
the vector in the CPU's handler table (I forget the name). They are
now all being set to the default interrupt trampoline, which
implements the second configuration level: The calling of any lisp
function, as specified by the "exception-handler" accessor.

> to pass some object as an argument to the handler function.

I don't quite understand what you mean by this?

--

-- 
Frode V. Fjeld
Permalink | Reply |
headers
Robert Swindells | 15 Jun 2009 14:59
Picon
Picon

Re: OS decisions


Frode V. Fjeld <frodef <at> cs.uit.no> wrote:
>Robert Swindells <rjs <at> fdy2.demon.co.uk> writes:
>
>> The interrupt handling sequence might benefit from some changes too,
>> I guess you could install a closure as the handler but it could be
>> simpler to pass some object as an argument to the handler function.

>As of now there's two mechanisms for setting up interrupt
>handlers. The lower-level one is pretty much exactly the setting of
>the vector in the CPU's handler table (I forget the name). They are
>now all being set to the default interrupt trampoline, which
>implements the second configuration level: The calling of any lisp
>function, as specified by the "exception-handler" accessor.

I know, but the trampoline only passes vector number and stack frame
to the handler.

The trampoline also doesn't allow for multiple devices sharing an
interrupt.

It would probably be a good idea to move the code to clear interrupts
below the level of the interrupt handlers, maybe test for non-nil
return value from the handler(s) before clearing it.

>> to pass some object as an argument to the handler function.
>
>I don't quite understand what you mean by this?

Most operating systems pass some object to interrupt handlers rather than
having to use global data. It simplifies the code when you have multiple
instances of a particular device.

Robert Swindells
Permalink | Reply |
headers
Frode V. Fjeld | 15 Jun 2009 15:25
Picon
Picon
Favicon

Re: OS decisions

Robert Swindells <rjs <at> fdy2.demon.co.uk> writes:

> The trampoline also doesn't allow for multiple devices sharing an
> interrupt.

How would this be allowed for?

My very vague idea of how shared interrupts work is that upon an
interrupt each handler is called in turn, and each must poll its
device to see if it requires service. But for all I know there's
something more sophisticated going on?

> Most operating systems pass some object to interrupt handlers rather
> than having to use global data. It simplifies the code when you have
> multiple instances of a particular device.

Oh, I see. As you mentioned my reasoning is/was that we have closures
for this (or conversely, "user objects" are a poor man's closures),
but adding a "user object" would be trivial, of course. It could even
be added just like so:

  (defun set-exception-handler-with-user-object (vector handler user-object)
    (setf (exception-handler vector)
      (lambda (frame stack)
        (funcall handler frame stack user-object))))

 :-)

--

-- 
Frode V. Fjeld
Permalink | Reply |
headers
Robert Swindells | 15 Jun 2009 15:56
Picon
Picon

Re: OS decisions


Frode V. Fjeld <frodef <at> cs.uit.no> wrote:
>Robert Swindells <rjs <at> fdy2.demon.co.uk> writes:

>> The trampoline also doesn't allow for multiple devices sharing an
>> interrupt.

>How would this be allowed for?

Maybe make the elements of the exception-handlers array be lists of
handlers and make the trampoline try each one until it sees a non-nil
return value.

>My very vague idea of how shared interrupts work is that upon an
>interrupt each handler is called in turn, and each must poll its
>device to see if it requires service. But for all I know there's
>something more sophisticated going on?

That is how it works.

Robert Swindells
Permalink | Reply |
headers
Brian Makin | 15 Jun 2009 00:55
Picon

Re: OS decisions


It's probably best if I stick to lisp code... and the easier stuff for  
the time being.
Anyone feel goon natured enough to help me get my feet wet in my first  
OOS project?

On Jun 14, 2009, at 1:08 PM, Robert Swindells wrote:

>
> Brian Makin wrote:
>>>>> What kind of file system? or use an existing one?
>>>>
>>>> I think an existing one would be fine.
>>>
>>> One option is to port LMFS from the MIT sources to Common Lisp.
>>>
>>> Robert Swindells
>
>> Other than versioning LMFS doesn't look too different from modern FS.
>
> Except that it is written in Lisp and designed to work in a single
> address space.
>
> It won't be as efficent but can probably be made to do something
> useful much faster than starting from scratch to copy another
> filesystem.
>
>> I'm just kind of thrashing around trying to find a place I can
>> effectively contribute :)
>
> There are plenty of places to contribute. What kind of thing do you
> want to work on ? Something at a high or low level ?
>
> High Level:
>
> Pick up code from SBCL or CMUCL for the top level file and io  
> functions.
>
> Do same for Simple Streams to add device-read and device-write, don't
> need the helper functions read-octets and write-octets though.
>
> Low Level:
>
> Modern PCs don't use the 8259 interrupt controller, they use the LAPIC
> and use ACPI to work out which interrupts are generated by which
> device. Someone could start looking at parsing the ACPI tables within
> Movitz.
>
> The interrupt handling sequence might benefit from some changes too, I
> guess you could install a closure as the handler but it could be
> simpler to pass some object as an argument to the handler function.
>
> Robert Swindells
> --
> A: Because it fouls the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
Permalink | Reply |
headers
Robert Swindells | 13 Jun 2009 00:43
Picon
Picon

Re: Threading Model and Parallelization Model inside Movitz


Ram Vedam wrote:
>I was wondering if the threading.lisp file inside the losp/ directory
>represents base threading model that Movitz is planning on
>supporting...  Also, is there an overarching design already in the
>works or is this an area that still needs to be worked on?

The current threading model has worked well for me.

There is a patch written by Shawn Betts that adds lispm style
processes on top of these threads, it also worked well for everthing
that I did with it.

Robert Swindells
Permalink | Reply |

Gmane