chaos-devel Mailing List for The chaos Operating System

Henrik Hallin wrote:

Hi Henrik,

> Can someone please copy the relevant text on how to set all of this up 
> to the wiki? Also, Per; cleaning up the main wiki page might be a good 
> idea?

I have cleaned up the HTML you spoke to me about on MSN. Putting this 
info up on the wiki should be done, I agree... Perhaps someone could do 
that? Ideally, we should have screenshots on what to choose in the 
different steps in the vmware config to make it trivial to set it up.

I encourage Someone to step up right now and help out with this. :-)

>> If you or anyone else wanna try it out anyway, here are the URLs.
>>
>> http://chaos.lundcom.se/download/vmware.img - chaos image for netbooting
>> in vmWare.  Set up a vmWare guest (in vmWare) system with this as A: and
>> networking enabled using vmnet8 (NAT networking).
>>
>> http://chaos.lundcom.se/download/Debian.vmdk
>> http://chaos.lundcom.se/download/Debian-flat.vmdk.bz2 - vmWare disk for
>> my small Debian installation.  Obviously, the bz2 one needs to be
>> decompressed.  Use this as the C: with SCSI (BusLogic as the controller
>> type) and you should be able to boot Debian with all the neccessary
>> stuff.  I realize now that I didn't actually install xemacs or any other
>> editor but it should be just an apt-get away...  Oh, use the same
>> network config for this one (i.e. vmnet8, NAT networking).  That way,
>> the chaos guest can access the Debian one and TFTP boot from it.
>>
>> Logon as root/chaos or chaos/chaos.  The chaos user has the chaos
>> sources in his home directory so the best way is probably to use this
>> one, either renaming it to something more personal or keeping it like
>> that.
>>
>> Any comments?  :-)  Of course, you or anyone else are very welcome to
>> improve on this, I have only done a quick and dirty work to get it
>> running.  And obviously, if someone finds and fixes the reason for the
>> page faults, be my guest...
>>
>> Now, back to the homework.  :)
>>   
> 
> 

-- 
Best regards,
Per Lundberg

Hi Guys,

Can someone please copy the relevant text on how to set all of this up=20
to the wiki? Also, Per; cleaning up the main wiki page might be a good id=
ea?

Henrik

Per Lundberg skrev:
> m=E5 2006-07-17 klockan 14:52 +0200 skrev Per Lundberg:
>  =20
>> If/when I'll have the time to do this, I'll also post a floppy image
>> that can be used to netboot with GRUB and vmware.
>>    =20
>
> It has been done.  The vmWare/GRUB compatibility seems a bit less than
> 100% but perhaps it would be improved if direct PCI access is used
> instead of BIOS; I'll have to try recompile GRUB with that flag and see
> if it makes a difference.  For now, what you have to do is when it
> "hangs" in the boot, press Ctrl-C and then press Enter twice to get bac=
k
> to the menu and reactivate the same option.  It loads perfectly then,
> but for some reason, a page fault :-) is caused which causes other page
> faults so it (chaos) doesn't seem to work 100% in vmWare.  I think we
> have had problems with chaos in vmWare before as well actually, but it
> works well in Bochs so it shouldn't be unsolvable by any means.
>
> If you or anyone else wanna try it out anyway, here are the URLs.
>
> http://chaos.lundcom.se/download/vmware.img - chaos image for netbootin=
g
> in vmWare.  Set up a vmWare guest (in vmWare) system with this as A: an=
d
> networking enabled using vmnet8 (NAT networking).
>
> http://chaos.lundcom.se/download/Debian.vmdk
> http://chaos.lundcom.se/download/Debian-flat.vmdk.bz2 - vmWare disk for
> my small Debian installation.  Obviously, the bz2 one needs to be
> decompressed.  Use this as the C: with SCSI (BusLogic as the controller
> type) and you should be able to boot Debian with all the neccessary
> stuff.  I realize now that I didn't actually install xemacs or any othe=
r
> editor but it should be just an apt-get away...  Oh, use the same
> network config for this one (i.e. vmnet8, NAT networking).  That way,
> the chaos guest can access the Debian one and TFTP boot from it.
>
> Logon as root/chaos or chaos/chaos.  The chaos user has the chaos
> sources in his home directory so the best way is probably to use this
> one, either renaming it to something more personal or keeping it like
> that.
>
> Any comments?  :-)  Of course, you or anyone else are very welcome to
> improve on this, I have only done a quick and dirty work to get it
> running.  And obviously, if someone finds and fixes the reason for the
> page faults, be my guest...
>
> Now, back to the homework.  :)
>  =20

Hello,

I recently thought of something that I figured some people here may have input 
on (though I don't know whether it is relevant to chaos).

Traditionally when writing applications in need of "logical" concurrency, one 
has had to choose between multithreading or implementing a state machine. 

Multithreading can mean the code can be much more easier to read, write and 
debug[1], while at the same time scaling with multiple CPU:s. The traditional 
downside is the heavy-weight nature of native threads. Alternatively, for 
pure user-space threading solutions, disadvantages tend to include 
non-preemptive scheduling and/or lack of time slicing.

Some languages provide a compromise in the form of userspace threads based on 
first-class continuations, with the library code taking advantage of the 
support for FCC to provide concurrent semantics for network I/O and the like. 
But even then you run into trouble with actions for which there is no 
select/poll/epoll/kqueue like interface.

All of this, it seems to me, is founded in the fact that Unix was 
essentiallydesigned for supporting applications written in C - a language 
where first-class continuations are not practical[2].

Imagine an operating system specifically targetted at languages with support 
for first-class continuations! In part, this would mean that *ALL* system 
calls would be asynchronous in nature and be designed such that the correct 
continuation can be efficiently dispatched at the completion of the call. 

Given such a foundation, continuation based userspace threads suddenly no 
longer have the limitations they traditionally have; with the exception of 
pre-emptive and/or time sliced scheduling, continuation based threads would 
be as useful as native threads are in traditional operating systems. And as 
far as I can see nothing prevents the continuation based threads to be 
scheduled among multiple traditional native threads (assuming the runtime is 
otherwise written with hardware concurrency in mind).

Taking a step further, perhaps one can even solve the scheduling issue. For 
those of you who know more about low-level stuff than me - is there any 
reason why it would *not* be feasable to do something along  the lines of 
asynchronously (in response to a timer interrupt) "inject" a call to the 
scheduler in a process' execution path, in a way which is compatible with the 
userspace calling convention?

If this is possible, the scheduler can be pre-emptively entered and scheduling 
can then proceed cleanly with no special case whatsoever. Because the call 
was made with the right calling convention and associated semantics, the 
scheduler can save the current continuation just as if the scheduler had been 
explicitly called "normally".

Any thoughts?

If this can be realized one can suddenly write massively concurrent (ala 
erlang) software; including massively scalable network servers without any 
need for state machines. The only overhead associated with a "thread" would 
be active references in its continuation; context-switching (at least 
non-preemptive) would be no more expensive than a function call.

[1] In spite of the "bad reputation" of multithreading, I have never had a 
problem with concurrency related bugs. Obviously there have been bugs, but no 
where near as often as with e.g. explicit memory management or unchecked 
memory access.

[2] For hand-written C that is; I am fully aware that languages with support 
for first-class continuatonis can be written in the form of a C code 
generator.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <pet...@in...>'
Key retrieval: Send an E-Mail to get...@sc...
E-Mail: pet...@in... Web: http://www.scode.org

[coming in late]

> Actually, I think it would go in the opposite direction. It adds
> complexity and complexity is always error prone. The only application
> I can think of at the top of my head where atomicity is a benifit is
> firewall configuration, most other configurations doesn't benefit at
> all.

Basically any application that maintaines state and ends up being broken after 
a crash could benefit. Certainlly, if crash resistence is important you 
currently have to simply ensure it is written in a way that enforces 
consistency. But imagine the simplicity (from the user application 
perspective) of everything being automatically consistent, by way of 
checkpointing the backing store when appropriate.

Ii wll conede though that this kind of usage could do with a proper database 
backend instead.

But imagine your average shell script. Imagine you could have an "ACID" bit on 
a script, "set -e" at the beginning of it, and have NOTHING the script (or 
its subprocesses) does affect anything unless the script exists with a status 
code of zero.

Neat :)

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <pet...@in...>'
Key retrieval: Send an E-Mail to get...@sc...
E-Mail: pet...@in... Web: http://www.scode.org

Johannes Lundberg wrote:
> On 7/26/06, Per Lundberg <pe...@gm...> wrote:
>> We could make a vmware image that has X and GNOME etc, but I don't know,
>> perhaps keeping it simple is a good idea.  I think it is nice to have it
>> be small for people with low-speed broadband etc.  If we make it too
>> simple, perhaps we get too many newbies trying to be kernel developers
>> with all the fatal consequences that will bring.  :-P
> I don't agree with this though. Don't forget that developers är users
> too. If they can spend less time setting up a development-environment,
> they can spend more time looking at chaos source code. Even if a
> developer isn't very experienced with kernel development, they can
> still give useful comments.. We just have to judge the quality of the
> code / idea, just as we would do anyway.

Yes, of course, I was a bit elitistic/childish.  :-)  But there is a 
point in what I'm saying: if it is too simple, we might attract people 
who are not very skillful and will require a lot of help with simple 
things.  And I personally don't have the kind of time to help those 
people.  So, for me it is better if the entry level is a bit higher. 
But if we have people here who are willing and able to hold people's 
hands and help them with trivial things, fine by me.  I have no problem 
with that.

> Is it possible to start the images and do a CVS-checkout, compile and
> testboot in the second VM already? If so, I should take a look at the
> latest. :)

Yes, it is certainly possible.  You don't even have to CVS checkout 
because the code is already checked out for you.

I am re-posting the URL:s for you and everyone else.  I encourage people 
to test these and see what kind of problems might occur.  (I get page 
faults here when booting.  :-)

http://chaos.lundcom.se/download/vmware.img - chaos image for netbooting
in vmWare.  Set up a vmWare guest (in vmWare) system with this as A: and
networking enabled using vmnet8 (NAT networking).

http://chaos.lundcom.se/download/Debian.vmdk
http://chaos.lundcom.se/download/Debian-flat.vmdk.bz2 - vmWare disk for
my small Debian installation.  Obviously, the bz2 one needs to be
decompressed.
--
Best regards,
Per Lundberg

-- 
Best regards,
Per Lundberg

-------- Vidarebefordrat meddelande --------
Från: Johannes Lundberg <joh...@gm...>
Till: Per Lundberg <pe...@gm...>
Ämne: Re: [chaos-devel] New snapshot released (2006-07-11)
Datum: Fri, 4 Aug 2006 09:05:44 +0200

On 7/26/06, Per Lundberg <pe...@gm...> wrote:
> We could make a vmware image that has X and GNOME etc, but I don't know,
> perhaps keeping it simple is a good idea.  I think it is nice to have it
> be small for people with low-speed broadband etc.  If we make it too
> simple, perhaps we get too many newbies trying to be kernel developers
> with all the fatal consequences that will bring.  :-P

I don't agree with this though. Don't forget that developers är users
too. If they can spend less time setting up a development-environment,
they can spend more time looking at chaos source code. Even if a
developer isn't very experienced with kernel development, they can
still give useful comments.. We just have to judge the quality of the
code / idea, just as we would do anyway.

Is it possible to start the images and do a CVS-checkout, compile and
testboot in the second VM already? If so, I should take a look at the
latest. :)