Does this mean you still delegate to something like KVM/paravirtualzation for your device models, but your FTL guest OS can run multiple secure workloads inside a VM?
Or are you designing a custom OS from the ground up to run on native hardware? What constraints are you putting on hardware support to make this a tractable that's not re-implementing all of the stuff that linux has? I assume that's why it's advertised for the "cloud", because you know a priori the deployment machines you're gonna run on? Or is hardware support known by kernel devs to be a (relatively) trivial problem in the OS space, compared to the user-facing features (like processes, scheduling, memory management, etc)?
Or is the bet that microkernel = win = can implement everything linux has and more?
I'm curious about the eventual end goal for the project is, not just what currently exists (as otherwise the answer currently seems to be sentence 1)
> The user space is the easy part. A historical issue defining our computer landscape is that modern kernels try really hard to provide the illusion of a blocking API. You write a file, which takes time then you continue when it’s done. This is smoke and mirrors, this isn’t how hardware works at all! It’s always fire and forget: Write this, here’s a region of memory, wake me up when it’s over. It’s fundamentally asynchronous. The OS provides these thread and process abstractions which make you think the API’s blocking. The horrible side effect’s that language designers get an out of jail card for async programming, they don’t have to think about it! When writing to a file, they don’t need to make sure the bytes aren’t moved during the operation while running something. No, you just bind to the POSIX API and enjoy this blocking world illusion. - Matklad <a href="https://alexalejandre.com/interviews/interview-with-matklad/" rel="nofollow">https://alexalejandre.com/interviews/interview-with-matklad/
Wow. This is genuinely the first time I have come across this idea. Are there Kernels build to be completely async? I understand they would be experimental. And the whole stack runs in a async environment from say the web server rendering templates - down to the kernel loading data into the cpu cache? Does it offer performance advantages? I got so many questions…
sigbottle · · focus · HN ↗
Does this mean you still delegate to something like KVM/paravirtualzation for your device models, but your FTL guest OS can run multiple secure workloads inside a VM?
Or are you designing a custom OS from the ground up to run on native hardware? What constraints are you putting on hardware support to make this a tractable that's not re-implementing all of the stuff that linux has? I assume that's why it's advertised for the "cloud", because you know a priori the deployment machines you're gonna run on? Or is hardware support known by kernel devs to be a (relatively) trivial problem in the OS space, compared to the user-facing features (like processes, scheduling, memory management, etc)?
Or is the bet that microkernel = win = can implement everything linux has and more?
I'm curious about the eventual end goal for the project is, not just what currently exists (as otherwise the answer currently seems to be sentence 1)
veqq · · focus · HN ↗
tecoholic · · focus · HN ↗