this post was submitted on 07 Jul 2024
835 points (92.6% liked)

linuxmemes

21192 readers
911 users here now

Hint: :q!

Sister communities:

Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
    • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
    • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

    • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
    poopsmith@lemmy.world
    zephyr@lemmy.world
    rtxn@lemmy.world
    835
    No Mercy (files.catbox.moe)
    submitted 4 months ago by sag@lemm.ee to c/linuxmemes@lemmy.world
    162 comments fedilink hide all child comments
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] aubeynarf@lemmynsfw.com 15 points 4 months ago* (last edited 4 months ago) (2 children)

    Performance is the major flaw with microkernels that have prevented the half-dozen or more serious attempts at this to succeed.

    Incurring context switching for low-level operations is just too slow.

    An alternative might be a safe/provable language for kernel and drivers where the compiler can guarantee properties of kernel modules instead of requiring hardware guarantees, and it ends up in one address space/protection boundary. But then the compiler (and its output) becomes a trusted component.

    [–] nickwitha_k@lemmy.sdf.org 3 points 4 months ago (1 children)

    Thank you. Came here to say this. Microkernels are great for limited scope devices like microcontrollers but really suffer in general computing.

    [–] uis@lemm.ee 1 points 4 months ago (1 children)

    Quite opposite. Most firmware microcontrollers run is giant kernel. Some microcontrollers don't even have context switching at all. And I'm not even starting to talk about MMU.

    [–] nickwitha_k@lemmy.sdf.org 4 points 4 months ago (1 children)

    I was not meaning to say that all microcontrollers (or microcontroller firmwares) run a microkernel but, rather, that microcontrollers are an environment where they can work well because the limited scope of what the device is expected to do and its necessarily supported peripherals can be much smaller, making the potential impact of context changes smaller.

    For some good examples of microkernels for such purposes, take a look at FreeRTOS, ChibiOS, or Zephyr pre-1.6 (at which point architecture changed to a monolith because it is creeping towards general computing functionality).

    Some microcontrollers don't even have context switching at all.

    As long as there's some processing RAM and sufficient ROM, I'm sure that it can be crammed in there via firmware (in a sub-optimal way that makes people who have to maintain the code, including your future self, hate you and wish a more appropriate part were used).

    And I'm not even starting to talk about MMU.

    Some madlads forked Linux to get it to work without an MMU, even getting it merged into the mainline kernel: https://en.m.wikipedia.org/wiki/%CE%9CClinux

    So, doable. Adviseable? Probably not in most cases but that's subjective.

    [–] uis@lemm.ee 2 points 4 months ago (1 children)

    take a look at FreeRTOS

    AFAIK FreeRTOS always ran drivers in kernel.

    As long as there's some processing RAM and sufficient ROM, I'm sure that it can be crammed in there via firmware

    You can't even emulate MPU without MPU. The only way is running bytecode, which is still not context switching.

    Some madlads forked Linux to get it to work without an MMU, even getting it merged into the mainline kernel: https://en.m.wikipedia.org/wiki/%CE%9CClinux

    You are correct here. Should have said MPU instead.

    [–] nickwitha_k@lemmy.sdf.org 2 points 4 months ago

    AFAIK FreeRTOS always ran drivers in kernel.

    At least in the docs, I see it described as a microkernel but, with a kernel that small, the differences are probably academic (and I'll leave that to people with more formal background in CS than myself).

    You can't even emulate MPU without MPU. The only way is running bytecode, which is still not context switching.

    You are correct here. Should have said MPU instead.

    Oh yes! That makes a lot more sense. I've been on-and-off looking at implementing multithreading and multiprocessing in CircuitPython. Memory protection is a big problem with making it work reliably.

    [–] uis@lemm.ee 2 points 4 months ago

    where the compiler can guarantee properties of kernel modules instead of requiring hardware guarantees

    Then you would need to move compiler to kernel. Well, there is one: BPF(and derivatives). It's turing-incomplete by design.