Forum: Ruby Ruby OS

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
A2784809909ef88591afd19126c83993?d=identicon&s=25 Sparky Mat (sparkymat)
on 2009-06-04 10:14
I was considering porting the Ruby 1.9 VM to bare metal (something
similar to Cleese - http://code.google.com/p/cleese/). I was wondering
if someone is already working on this. The end goal is to have a Ruby
OS, with everything running on the VM. I have yet to analyze the
complete changes needed.

My original idea was for such a (Ruby) OS to be coupled with a versioned
file-system to have a completely rollback-able OS where the whole
userland and parts of the system land are in pure Ruby, with patches
being .diff files :-) .

I have a discussion running on the OSDev forums regarding this (Link:
http://forum.osdev.org/viewtopic.php?f=15&t=20220)

So is there such a project already?

TLDR: Is someone working on porting the Ruby 1.9.x VM to bare metal?
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2009-06-04 11:46
(Received via mailing list)
Hi,

I know one laboratory trying to such a kernel (where I had been when I'm
a student).

# And this lab made a Perl OS, last year.
Ba91caa4b1fd66471e4180151b379dd7?d=identicon&s=25 Jörg W Mittag (Guest)
on 2009-06-04 14:00
(Received via mailing list)
Sparky Mat wrote:
> I was considering porting the Ruby 1.9 VM to bare metal (something
> similar to Cleese - http://code.google.com/p/cleese/). I was wondering
> if someone is already working on this.

I don't know for YARV, but I know that there was a thread on the
Rubinius mailing list, where one guy was working on porting Rubinius
running on a microcontroller. It doesn't look like it's gone anywhere,
though, but you could definitely contact him.

Here's the thread:

  <https://Groups.Google.Com/group/rubinius-dev/brows...

jwm
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-04 14:13
(Received via mailing list)
On 4 Jun 2009, at 09:14, Sparky Mat wrote:
> I was considering porting the Ruby 1.9 VM to bare metal (something
> similar to Cleese - http://code.google.com/p/cleese/). I was wondering
> if someone is already working on this. The end goal is to have a Ruby
> OS, with everything running on the VM. I have yet to analyze the
> complete changes needed.

My colleague and I have been toying with a similar idea for a couple
of years now, but we're more interested in a register-based VM than
YARV and haven't managed to settle on one yet (if only Google would
open-source Dalvik...).

We've also done some proof-of-concept work to see if writing a Unix
userland in pure Ruby is possible and I'm hoping the two ideas will
merge into something useful at some point.

 From a maintenance perspective Ruby would make for a pretty sweet
systems programming language and assuming a build which supports ruby/
dl or ffi then all the functionality of C is there - or with Wilson
even assembler.

> My original idea was for such a (Ruby) OS to be coupled with a
> versioned
> file-system to have a completely rollback-able OS where the whole
> userland and parts of the system land are in pure Ruby, with patches
> being .diff files :-) .

The idea of a transactional file system does sound rather interesting
- especially if it were backed by transactional memory.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
9dec3df8319c613f6f4f14a27da0fdb4?d=identicon&s=25 Kyle Schmitt (Guest)
on 2009-06-04 15:16
(Received via mailing list)
On Thu, Jun 4, 2009 at 3:14 AM, Sparky Mat <max@sparkymat.net> wrote:
> I was considering porting the Ruby 1.9 VM to bare metal (something
> similar to Cleese - http://code.google.com/p/cleese/). I was wondering
> if someone is already working on this. The end goal is to have a Ruby
> OS, with everything running on the VM. I have yet to analyze the
> complete changes needed.


Umm, have you thought perhaps of using an existing kernel and just
having one binary, that being ruby?  You could then build your whole
userspace on top of that.

I've toyed with the idea, but never had the time to really do it.

It's easy, take a linux, BSD (or any other "Real OS"â„¢), and add an
entry into the bootloader, telling it that the init program is
whatever binary or executable script you wish.  You could add entries
for irb, a commodore 64 basic interpreter, and an apple-basic
interpreter in less than 5 minutes.

I know just booting into irb or commodore basic may count as an OS
from the 8-bit days, but it really doesn't cut it now days :)  So
after proving it works to yourself, try writing your own init as a
ruby 1.9 script.

my 2¢

--Kyle
42773b24e0c3fb506a8a875c058a9dd7?d=identicon&s=25 Dylan Evans (Guest)
on 2009-06-04 15:50
(Received via mailing list)
On Thu, Jun 4, 2009 at 11:15 PM, Kyle Schmitt
<kyleaschmitt@gmail.com>wrote:

> userspace on top of that.
A peek inside the mind of a genius. Why not use existing code and
increase
your chances of success? You will have to use binary at some level, and
if
you did want to use ruby to write kernel modules you could perhaps build
on a microkernel (maybe minix) where the system is made up of daemons
running in user space.

Actually a simple way to prototype the system would be to run it in
ms-dos
which is as near to no operating system as you can get anyway.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-04 17:59
(Received via mailing list)
On 4 Jun 2009, at 14:49, Dylan Evans wrote:
> A peek inside the mind of a genius. Why not use existing code and
> increase
> your chances of success? You will have to use binary at some level,
> and if
> you did want to use ruby to write kernel modules you could perhaps
> build
> on a microkernel (maybe minix) where the system is made up of daemons
> running in user space.

Minix has a few shortcomings, but in general this approach is doable.
A better choice of kernel though would probably be NetBSD thanks to
the large number of hardware platforms that it supports.

> Actually a simple way to prototype the system would be to run it in
> ms-dos
> which is as near to no operating system as you can get anyway.

You can already run Ruby on top of MS-DOS so in a sense the experiment
has been done.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
42773b24e0c3fb506a8a875c058a9dd7?d=identicon&s=25 Dylan Evans (Guest)
on 2009-06-05 04:59
(Received via mailing list)
On Fri, Jun 5, 2009 at 1:58 AM, Eleanor McHugh <
eleanor@games-with-brains.com> wrote:

> On 4 Jun 2009, at 14:49, Dylan Evans wrote:
>
>
>  Actually a simple way to prototype the system would be to run it in ms-dos
>> which is as near to no operating system as you can get anyway.
>>
>
> You can already run Ruby on top of MS-DOS so in a sense the experiment has
> been done.
>

Yes, but just the interpreter, from there you could set up a multi
tasking
environment, somewhat like how win 9x worked, and because ms-dos is
fairly
trivial it wouldn't be a huge leap to writing device drivers in ruby.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-05 15:52
(Received via mailing list)
On 5 Jun 2009, at 03:58, Dylan Evans wrote:
>> experiment has
>> been done.
>>
>
> Yes, but just the interpreter, from there you could set up a multi
> tasking
> environment, somewhat like how win 9x worked, and because ms-dos is
> fairly
> trivial it wouldn't be a huge leap to writing device drivers in ruby.

I'm not sure it would even be that difficult - at least in principle -
to write device drivers for unix in Ruby as ruby/dl gives you memory
buffers and callbacks. However my DD experience is on other operating
systems that get in your way less (like OS/9) so there are probably
kernel interface complexities that I'm overlooking. Might be a fun
experiment to look into though if I can find the time.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
A2784809909ef88591afd19126c83993?d=identicon&s=25 Sparky Mat (sparkymat)
on 2009-06-08 10:09
Kyle Schmitt wrote:

> Umm, have you thought perhaps of using an existing kernel and just
> having one binary, that being ruby?  You could then build your whole
> userspace on top of that.
>

I suspect that this would be the most practical approach, and probably,
after failing the bare-metal thing, I would end up doing this. However,
I'd still like to give the bare-metal port a try.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-08 15:11
(Received via mailing list)
On 8 Jun 2009, at 09:10, Sparky Mat wrote:
> However,
> I'd still like to give the bare-metal port a try.

Well keep us informed on how it goes. I could really use a bare-metal
Ruby but I don't have the time to work on it right now :(


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-06-08 16:28
(Received via mailing list)
2009/6/8 Sparky Mat <max@sparkymat.net>:
> Kyle Schmitt wrote:
>
>> Umm, have you thought perhaps of using an existing kernel and just
>> having one binary, that being ruby?  You could then build your whole
>> userspace on top of that.
>>
>
> I suspect that this would be the most practical approach, and probably,
> after failing the bare-metal thing, I would end up doing this. However,
> I'd still like to give the bare-metal port a try.

What would you want the bare-metal port to do? If you just want to run
in-memory without using any hardware devices like disk drives,
graphics, etc it would be fairly simple.

However, there's a reason why Linux and BSDs have bazzilions of
drivers that took years to develop and debug and half of them are
still failing half of the time. There's simply way too much different
hardware which is either not documented or has undocumented bugs so
you will have hard time if you try to run on bare metal and support
any hardware but the main memory.

Exotic microkernels won't help you either because they suffer from the
same basic problem: they don't have drivers for most hardware so the
chance you can boot anything based on them on your machine is pretty
small.

The bare-metal approach is only viable for specialized applications
where you select and buy a well documented piece of hardware and port
the system to that.

Thanks

Michal
34a7615f38496a5dafbb3e6b721c435e?d=identicon&s=25 Mohit Sindhwani (Guest)
on 2009-06-08 16:44
(Received via mailing list)
Eleanor McHugh wrote:
>> I'd still like to give the bare-metal port a try.
>
> Well keep us informed on how it goes. I could really use a bare-metal
> Ruby but I don't have the time to work on it right now :(
I wish I had the time :(

Cheers,
Mohit.
6/8/2009 | 10:43 PM.
Fa2521c6539342333de9f42502657e5a?d=identicon&s=25 Eleanor McHugh (Guest)
on 2009-06-08 18:32
(Received via mailing list)
On 8 Jun 2009, at 15:43, Mohit Sindhwani wrote:
>>> I suspect that this would be the most practical approach, and
>>> probably,
>>> after failing the bare-metal thing, I would end up doing this.
>>> However,
>>> I'd still like to give the bare-metal port a try.
>>
>> Well keep us informed on how it goes. I could really use a bare-
>> metal Ruby but I don't have the time to work on it right now :(
> I wish I had the time :(

It's the one thing there's never enough of.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
A2784809909ef88591afd19126c83993?d=identicon&s=25 Sparky Mat (sparkymat)
on 2009-06-09 05:44
Michal Suchanek wrote:

> However, there's a reason why Linux and BSDs have bazzilions of
> drivers that took years to develop and debug and half of them are
> still failing half of the time. There's simply way too much different
> hardware which is either not documented or has undocumented bugs so
> you will have hard time if you try to run on bare metal and support
> any hardware but the main memory.
>
> Exotic microkernels won't help you either because they suffer from the
> same basic problem: they don't have drivers for most hardware so the
> chance you can boot anything based on them on your machine is pretty
> small.
>

I agree with most of what you've said, and yes, I don't want to spend
the next few years writing/re-writing drivers just to get stuff working.
I had already shelved my Minix setup yesterday and am now setting up a
RubyVM on Linux kernel. Well, starting with a default Debian
installation and stripping out stuff now.
F889bf17449ffbf62345d2b2d316a937?d=identicon&s=25 Michal Suchanek (Guest)
on 2009-06-09 11:46
(Received via mailing list)
2009/6/9 Sparky Mat <max@sparkymat.net>:
>> same basic problem: they don't have drivers for most hardware so the
>> chance you can boot anything based on them on your machine is pretty
>> small.
>>
>
> I agree with most of what you've said, and yes, I don't want to spend
> the next few years writing/re-writing drivers just to get stuff working.
> I had already shelved my Minix setup yesterday and am now setting up a
> RubyVM on Linux kernel. Well, starting with a default Debian
> installation and stripping out stuff now.


Note that on Linux many drivers (filesystem, USB, parallel, ...) can
be written in userspace so you can still use any language you like for
these. Hopefully the number of subsystems that are open in this way
will increase over time.

Thanks

Michal
This topic is locked and can not be replied to.