runtimejs / runtime

[not maintained] Lightweight JavaScript library operating system for the cloud
http://runtimejs.org
Apache License 2.0
1.93k stars 128 forks source link

Inclusion of linux kernel modules #12

Closed kjnsn closed 10 years ago

kjnsn commented 10 years ago

Since it would be extremely difficult to write our own drivers for everything, being able to use the existing linux modules would be really beneficial.

piranna commented 10 years ago

Don't know if it would be difficult due to Linux kernel modules architecture... Also, the idea is to develop them in Javascript, but probably could there be some binary bindings and a Linux modules loader. On the other hand, I believe we should take a look how Minix 3 drivers works, their architecture is fairly reliable and somewhat similar to how runtime.js is designed.

Anyway, we should better take a look on some of the universal driver descriptors that are designed just to fix this problem. Unluckily there's not too much support from FOSS OSes, because they would be an open door for closed binary blobs, so there almost no drivers, only from kernel hobbyist :-( El 01/07/2014 05:12, "kjnsn" notifications@github.com escribió:

Since it would be extremely difficult to write our own drivers for everything, being able to use the existing linux modules would be really beneficial.

— Reply to this email directly or view it on GitHub https://github.com/runtimejs/runtime/issues/12.

piranna commented 10 years ago

Some links regarding the Universal Driver Interface:

http://en.wikipedia.org/wiki/Uniform_Driver_Interface http://wiki.osdev.org/Uniform_Driver_Interface http://wiki.osdev.org/UDI_Driver_Loading

and some other interesting related links:

http://en.wikipedia.org/wiki/Universal_Network_Device_Interface http://wiki.osdev.org/User:Turdus/Universal_Driver_Block_Format http://forum.osdev.org/viewtopic.php?f=15&t=17731&start=0 http://christopher-technicalmusings.blogspot.com.es/2012/04/call-to-revive-uniform-driver-interface.html

iefserge commented 10 years ago

I think, it would be easier to target just KVM/QEMU/XEN for now. We can provide support for virtio devices, this will give us access to network and disks.

dorlaor commented 10 years ago

On Wed, Jul 2, 2014 at 11:11 PM, Serge notifications@github.com wrote:

I think, it would be easier to target just KVM/QEMU/XEN for now. We can provide support for virtio devices, this will give us access to network and disks.

May I offer an extreme suggestion(?): How about integrating this impressive project with the http://osv.io project?

OSv is a library OS for virtual machines. It was designed to be slim as possible and to support various runtimes (mainly JVMs but we run native Ruby and C++ today).

We share a common vision, we have existing drivers for kvm, xev, vmware and vbox, we have smp support and better tcp stack from any other OS and we have ZFS as filesystem.

OSv is written in c++ and tried to support several modern runtimes. We have specific ideas how the jvm can be modified in order to use the low level apis in the kernel. For example, v8 will be able to control scheduling, zero copy and even the page tables in case it wishes. When we re-wrote memcached we got a x4 performance gain.

There is not reason why v8 shouldn't enjoy for the very same ideas and be a preferred runtime of choice in the unified project. I'm sure that OSv has lots to gain from this cooperation too.

— Reply to this email directly or view it on GitHub https://github.com/runtimejs/runtime/issues/12#issuecomment-47829341.

groundwater commented 10 years ago

v8 will be able to control scheduling, zero copy and even the page tables

I'm pretty sure under this model we're only looking at a single page table. You don't need hardware memory protection because v8 gives you a memory sandbox.

ghost commented 10 years ago

This is a bit off topic but I did this once - I compiled nodejs as static binary and made a linux from scratch and used the node.js binary as /sbin/init (forgot what it is called).

dorlaor commented 10 years ago

On Thu, Jul 3, 2014 at 9:09 AM, Jacob Groundwater notifications@github.com wrote:

v8 will be able to control scheduling, zero copy and even the page tables

I'm pretty sure under this model we're only looking at a single page table. You don't need hardware memory protection because v8 gives you a memory sandbox.

In the JVM case, sometimes the virtual address space isn't flat because applications use JNI to memory map files. I have no idea if it's possible in java script.

In addition, if you implement a garbage collector it can enjoy access to the dirty bit hardware mapping. Lastly, we have a neat ballooning technique where we lend memory from the runtime and give it to the kernel and vise verse as a function of memory pressure.

Besides the page tables, the schedule api is valuable enough to play. You can register idle time polling functions, time wheel, etc. Worth checking.

— Reply to this email directly or view it on GitHub https://github.com/runtimejs/runtime/issues/12#issuecomment-47870245.

piranna commented 10 years ago

This is a bit off topic but I did this once - I compiled nodejs as static binary and made a linux from scratch and used the node.js binary as /sbin/init (forgot what it is called).

This is just what NodeOS does, where @groundwater and me we are working on. There are other similar projects like AnarchyOS by @subtrack and others :-)

notslang commented 10 years ago

@bobef you hooked up node as your shell. This is using node as the kernel.

heapwolf commented 10 years ago

This answer seems to satisfy this thread.

I think, it would be easier to target just KVM/QEMU/XEN for now. We can provide support for virtio devices, this will give us access to network and disks.

mikeal commented 10 years ago

Speaking of virtualization layers and virtio, it might be best to take the "legacy free" approach that bhyve (FreeBSD's new hypervisor) has taken.

http://bhyve.org/faq/

Basically, only support CPU's from Intel with EPT and AMD chips with RVI.