I don't think the "complex web of objects to be deallocated" scenario is usually a problem, but I generally agree with your points. As always, careful design and control of the software is important. Abstractions are limited; spend them carefully.
The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages? Essential complexity can only be rearranged, not removed. Nothing changes the fact that every interface between hardware and software needs to be bridged.
On a different note: why should the kernel even handle IPC or scheduling? Those take the basic capabilities of context switching, timer management, and memory management. Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server? Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction. Everything else either follows from the hardware or is left to the whims of software.
> The kernel, the memory manager and device drivers, the language runtimes for managed languages; would these not be written in "systems" languages?
The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.
> On a different note: why should the kernel even handle IPC or scheduling?
Because any other solution will quickly run into chicken-and-the-egg style problems.
> Those take the basic capabilities of context switching, timer management, and memory management.
Yes. But only one timer, the rest should be free to use by other applications.
> Even "core functionality" can be a context switch (or a few) away; is a syscall not just a message to a system server?
No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.
> Only the most basic form of communication is necessary to delegate arbitrary functionality, so a true microkernel should only introduce that as an abstraction.
Indeed. And they do.
> Everything else either follows from the hardware or is left to the whims of software.
A lot of the stuff that 'follows from the hardware' can be dealt with at the application level.
> The kernel and memory manager: probably yes, the device drivers: not necessarily, the language runtimes for managed languages: not necessarily.
The parts that touch hardware (or similarly bare kernel interfaces) must be so. Sure, you could split device driver implementations and so on, but somewhere there's a meaningful lower level of software within the system.
> Because any other solution will quickly run into chicken-and-the-egg style problems.
No. The kernel must provide for context switching. It would be like migrating threads IPC, but one-way. No threads, no scheduler, no dedicated data transfer. In other words, the bare minimum necessary to make a sensible abstraction around switching processes.
seL4, according to its developers, is not absolutely a microkernel. I believe the rationale mainly points to the in-kernel scheduler, but seL4's IPC interacts with the scheduler and is noticeably more elaborate than a mere context switch. Even if seL4's IPC is, by most standards, minimal, I do not consider it to be so objectively. I described a meaningfully more minimal alternative.
Delegating scheduling to userspace is trivial. If necessary, designate a scheduler to run if no scheduling decision is available. It has been done before, and the only usual objection is performance.
> No. A syscall is usually defined as a call to a ring one level in from the one where you currently are. But lots of things that are syscalls right now do not necessarily have to be.
Just as hardware interrupts can be abstracted into messages, syscalls can be abstracted into messages. I'm not saying that the hardware implementation directly conforms to the abstraction.
> The parts that touch hardware (or similarly bare kernel interfaces) must be so.
That's just a choice and no you are incorrect. It is perfectly possible to deal with hardware in managed languages.
> Sure, you could split device driver implementations and so on, but somewhere there's a meaningful lower level of software within the system.
This is optional. Been there, done that. Many times.
> No. The kernel must provide for context switching. It would be like migrating threads IPC, but one-way. No threads, no scheduler, no dedicated data transfer. In other words, the bare minimum necessary to make a sensible abstraction around switching processes.
Yes, IPC is context switching. Timer interrupts can cause extra context switches.
> seL4, according to its developers, is not absolutely a microkernel. I believe the rationale mainly points to the in-kernel scheduler, but seL4's IPC interacts with the scheduler and is noticeably more elaborate than a mere context switch. Even if seL4's IPC is, by most standards, minimal, I do not consider it to be so objectively. I described a meaningfully more minimal alternative.
It is a pretty poor implementation in my opinion.
> Delegating scheduling to userspace is trivial. If necessary, designate a scheduler to run if no scheduling decision is available. It has been done before, and the only usual objection is performance.
It's trivial, except for the little problem that your userspace program can be killed and then you have no scheduler.
> Just as hardware interrupts can be abstracted into messages, syscalls can be abstracted into messages. I'm not saying that the hardware implementation directly conforms to the abstraction.
Ok. If you want to use a different description of the term syscall than is common then that's fine but you should define that up front. Your definition of a syscall simply does not match mine.
> It is perfectly possible to deal with hardware in managed languages.
Perhaps we're using the words in different ways. What I mean is: in order to interact with something, it must either be done directly or through abstraction. If abstraction is used, it must be realized without itself. A language such as Java or C#, at least for performance, must expose some things on a lower level that the runtime normally abstracts away. (Or, say, the OS memory manager can't use virtual memory before it enables virtual memory.) Technically, the lower level could be programmed with a dialect of Java/C# or something like that, or there may be another level of abstraction that hides the details (a compiler generating code in the background, for example). But something has to be the first step at the bottom.
> Yes, IPC is context switching.
(Considering the diversity of how OSes approach context switches/IPC, I use "context switch" to mean "CPU mode/address space switch", more or less.)
Usually, IPC is context switching and overhead. seL4's IPC has overhead involved with scheduling, threads, and message buffering. My design isolates the context switching, which is common to all IPC designs.
> Timer interrupts can cause extra context switches.
I don't see what your point is. I assure you that my system is not uniquely fragile to timer interrupts.
> It's trivial, except for the little problem that your userspace program can be killed and then you have no scheduler.
Then don't let the scheduler be killed. What is the difference between a privileged userspace program and a kernelspace program? Isn't that what microkernels demonstrate? Again, this has been done before.
> Ok. If you want to use a different description of the term syscall than is common then that's fine but you should define that up front. Your definition of a syscall simply does not match mine.
It wasn't quite a definition, though I did write poorly. In the abstract, a syscall can be seen as a message. If IPC ("to a process") is done by putting some data somewhere, setting a few registers to special values, and executing a magic syscall instruction, then a normal syscall can be considered IPC "to the kernel".
Rust's strict ownership model isn't flexible enough sometimes (particularly when dealing with hardware concepts), so I consider it a "mostly good enough" abstraction that is a good default but should be circumvented sometimes.
That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust. Rust recognizes allocations on a language basis, but does not provide the same level of control over allocations on a language basis as Zig does. For instance, there is no stable interface for custom allocators for alloc/std.
std may not yet provide a stable interface for custom allocators (the Allocator API appears to be available in unstable presently), but use of custom allocators is common in no-std rust environments like embedded. Reading through https://github.com/irbull/custom_allocators the Allocator API doesn't seem particularly complicated. I think it's fair to expect that it will stabilize in time.
> That's like saying Rust has GC because GC libraries/runtimes can be implemented in/for Rust.
Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required. But if your application might benefit from GC, it's certainly available in the language. I might say "GC is optionally available in Rust if desired" to be more accurate.
> I think it's fair to expect that it will stabilize in time.
The allocator work is facing a lot of obstacles, unfortunately. I prefer it to be unstable for as long as it needs, though.
> Quite a few have already been implemented and are available as libraries exactly as you describe, today. I wouldn't phrase that as "Rust has GC" because that might imply that the GC is required.
This is exactly my point. Rust does not prevent GC by any means, but Rust also does not encourage GC by any means. The same goes for custom allocators, aside from the highly-unstable Allocator API.
> The allocator work is facing a lot of obstacles, unfortunately.
Got any links? Sounds like interesting reading. Seriously. Kind of thing I come here for. I'd really appreciate it. Or I can ask the AI for some.
> I prefer it to be unstable for as long as it needs, though.
Sure, same. Fully baking things is a process, and it's nice when things are fully baked. So I agree. I think Rust's async could be a bit more ergonomic, though it wasn't too difficult to wrap my head around, and sort of shockingly simple to implement a basic no-std async executor (~10 lines), so maybe I'm coming around. I was pleased to find out that it was simple enough that I could do it, and understand how it worked, as I try to do with all my microcontroller code, and wasn't dependent on a big async runtime like Tokio if I didn't need it's features (or bloat).
No, it isn't. Because that distinction is significant if you are using the language in an environment where those libraries are not available or suitable, such as the Linux project which uses a custom fork of Alloc which provides collections for different allocators.
So, that is not done at the language level but the library level. Unless the compiler is modified for Linux, but even if it is, that's entirely bespoke and unstable. This is not comparable to Zig's design. I'm aware that anything can be done if the right things are implemented; I'm talking about what Rust-the-language currently does for control over allocation. If the answer comes down to "we're doing something custom", then the language is soewhat or largely sidestepped. C-the-language certainly doesn't have panics or exceptions, even though longjmp or a custom runtime could be used.
I really like Rust, and I'll gladly accept if a language that advances its benefits appears. Just as Rust is available to avoid using C++, that language would be available to avoid using Rust. It's not a competition; it's pragmatism.
Rust has unsafe for the purpose of not requiring a magic compiler for all cases. It's not above-and-beyond the notion of augmenting an unsafe language with tooling; it just shifts the default mode of safety.
It's easier to focus on fewer representatives, and because the federal government has so much power (and then state governments), life-changing policies mainly come top-down. Power should instead flow bottom-up, with the top being the linchpin, but alas.
I'll say: respect the truth. That doesn't mean a lie should never be uttered, because a lie on one hand can affirm a greater truth on the other hand. (What is said must always be juxtaposed with what isn't said.) Moreover, being kind is not wholly contingent on speaking in some manner of (dis)honesty or (lack of) discretion. Being kind isn't the same as making people happy in the moment.
In this case, I think the grammar is just wrong: an em dash with spaces around it! Although I'm not so much of a stickler that I'd personally consider this to be a problem.
An em-dash (in this use, there are others where the normal style differs) set with regular spaces around it isn’t a grammar problem; it is a less common style preference (usually they are set closed—without spaces—or surrounded by thin spaces, or an en-dash surrounded by regular spaces is used instead.)
Rust is still young, so it's taking the opportunity to thoroughly explore its options. As it grows older, it will solidify its decisions, even if it means committing to something that will be broken in the future. I look forward to the day that it becomes legacy (with all love)!
reply