MotorOS: a Rust-first operating system for x64 VMs

Post by [deleted] » Mon, Jan 08, 2024, 7:34 AM UTC

weinzierl wrote: post #48

wavemode wrote: post #38

Earlier quoted context omitted.

You don't need very many device drivers to run in a VM. The real question is, how useful is a non-C-compatible, non-Linux-compatible, VM-only OS. Maybe a little bit, for microservices?

According to The American Heritage Dictionary an operating system is: "Software designed to control the hardware of a specific data-processing system in order to allow users and application programs to make use of it." The question is how much Operating System is a software that delegates all "control the hardware" parts to the layer below. I know there are wider definitions of OS, but my point is this is not going t…

Post by haarts » Mon, Jan 08, 2024, 7:43 AM UTC

seanw444 wrote: post #34

cedws wrote: post #9

It sounds like a cool project and I hope it continues development, but there is such a huge graveyard of such projects that have never gone anywhere that I struggle to get excited about them anymore. Replacing Linux is really hard, even for specific uses like cloud.

Replacing Linux is hard even for the BSDs, and those are very well established and considered basically next-in-line for similar tasks.

Post by slau » Mon, Jan 08, 2024, 8:42 AM UTC

wavemode wrote: post #38

weinzierl wrote: post #33

Sounds interesting, but it also reminds me of what Linus once said when asked about fearing competition. From my memory his answer was something like: I really like writing device drivers. Few people like that and until someone young and hungry comes along who likes that I'm not afraid of competition.

You don't need very many device drivers to run in a VM. The real question is, how useful is a non-C-compatible, non-Linux-compatible, VM-only OS. Maybe a little bit, for microservices?

Post by jacquesm » Mon, Jan 08, 2024, 9:01 AM UTC

Post by jacquesm » Mon, Jan 08, 2024, 9:06 AM UTC

wavemode wrote: post #37

micahcc wrote: post #36

> a simple multi-processor round robin (SMP) > the kernel is very small and does not block, so does not need to be preemptible I don't believe you and I don't even need to look at the code to know this is false.

Care to elaborate?

    // The scheduler.
    //
    // As the kernel supports wait/wake/swap, and no blocking in the kernel
    // other than wait, any kind of more sophisticated scheduling policy
    // can be implemented in the userspace (in theory; maybe tweaks are needed
    // to make things perform well in practive).
    //
    // So the default scheduler here is rather simple, but should work
    // for a lot of use cases.
    //
    // Priorities: see enum Priority
    // Cpu affinity: a single CPU hint
    // Sched groups: none: everything within a priority is round robin, so
    // a process with many threads will negatively affect a process with few threads.
    //
    // This should be OK for most situations: if there is a need for isolation,
    // just use another VM.