[HN Gopher] Managarm: Pragmatic microkernel-based OS with asynch...
___________________________________________________________________
Managarm: Pragmatic microkernel-based OS with asynchronous I/O
Author : ksp-atlas
Score : 61 points
Date : 2024-07-27 19:06 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jcelerier wrote:
| people always say that C++ is not a good fit for kernels, but so
| far this is the only language I know where small teams or
| individuals are regularly able to create non-trivial hobby OSes
| from scratch that go from zero to GUI:
|
| - Serenity (https://github.com/SerenityOS/serenity) - not really
| a small team, but it managed to get to GUI as pretty much a one-
| man-show
|
| - Skift (https://github.com/skift-org/skift)
|
| - hhu: https://github.com/hhuOS/hhuOS
|
| - MaxOS: https://github.com/maxtyson123/MaxOS
|
| - MorphiOS: https://github.com/syedtaqi95/morphiOS
|
| - Macaron: https://github.com/MacaronOS/Macaron
|
| - Ghost: https://github.com/maxdev1/ghost
|
| most big ones in C don't manage to get to the GUI level, except
| toaruos: https://github.com/klange/toaruos
| mananaysiempre wrote:
| HelenOS[1] is in C and has a GUI. I don't know how many people
| participated over its (quite extensive) history.
|
| Axle[2] is a one-man project with a GUI that the author has
| been gradually transitioning from C to Rust.
|
| Among C++ projects, I think Essence[3] also merits a mention.
|
| [1] http://www.helenos.org/
|
| [2] https://github.com/codyd51/axle
|
| [3] https://gitlab.com/nakst/essence
| ironhaven wrote:
| There is Redox written in rust. https://gitlab.redox-
| os.org/redox-os/redox
| fbdab103 wrote:
| Is the kernel really the differentiator there? seL4 is a Proven
| microkernel that is some 9000 lines of C. This ancient SO
| post[0] claims Linux is 140k lines. The kernel is just a tiny
| component of the many things required to get an OS up and
| running. I suspect most projects just peter out as the enormity
| of the complexity becomes apparent.
|
| [0] https://unix.stackexchange.com/questions/223746/why-is-
| the-l...
| monocasa wrote:
| That's just the architecture and driver independent part of
| the kernel. The kernel source tree is 15M lines or so.
| asveikau wrote:
| I think C++ is especially good for a GUI.
|
| The two counter-examples I can think of with plain C:
|
| * GTK+, though honestly speaking I think quality has dipped
| over the decades where C++ equivalents have flourished.
|
| * Old school Win32 style. Counter to the bad reputation, I find
| it easy to be productive with in plain C once you adjust your
| mental model to its expectations. Though it's probably better
| from C++ than C, for a few convenience features to reduce
| boiler plate.
| mananaysiempre wrote:
| Old Win32 style received less attention than it deserves, I
| think. It's an object system in its own right--a Smalltalkish
| one, at that, with an (admittedly muddled) E-style separation
| of synchronous and asynchronous calls!--but one rarely sees
| it mentioned in the same sentence as Objective-C, C++, and
| GObject/Vala. Part of the blame for that undoubtedly rests on
| Microsoft's incompetence at documenting concepts, but
| whatever the causes I'd definitely like to see that corner of
| the object-system design space explored more, with or without
| GUIs.
| asveikau wrote:
| When win32 was dominant they didn't need to document it,
| people had the motivation to figure it out.
|
| Successive waves of Microsoft people then tried to make it
| easier to use or replace it entirely, which, they never did
| so with the same quality as the original.
|
| Unfortunately some of those misadventures became synonymous
| with building a windows UI.
| tomcam wrote:
| > Part of the blame for that undoubtedly rests on
| Microsoft's incompetence at documenting concepts
|
| I mean Charles Petzold did that so successfully redoing it
| would be superfluous
| mananaysiempre wrote:
| Kind of. He stops somewhat short of admitting that
| Win16/32 windows _are_ objects and their graphical
| representation is mostly incidental. That's not a
| deficiency in his book--it's introductory on many topics,
| in a good way, and just dropping such an idea somewhere
| in the beginning portions would be more confusing than
| helpful for the intended audience.
|
| (That audience would almost certainly not be helped by
| the observation that they are dealing with a sort of
| Smalltalkish/Actorish system with badly bolted-on
| multithreading--most of it wouldn't know what that meant,
| at the time.)
|
| Still, this is kind of a common theme. Perhaps "you had
| to have been there" worked as an approach to
| documentation for the first ten to fifteen years, but
| afterwards any newcomer is just guaranteed to get lost.
|
| If you want to learn Win32, you need to read Petzold. If
| you're interested specifically in how the dialog manager
| works, you need to invent a time machine and read a
| series of blog posts Raymond Chen wrote in 2005[1]. If
| you want the particulars on message queueing, you need to
| invent a time machine and read the chapter about then in
| Raymond Chen's blogobook[2]. If you want to learn about
| STRICT and the very useful message cracker macros in
| WINDOWSX.H, first, you were probably reading Raymond
| Chen, because the official documentation is basically mum
| about it, but second, you need to track down that one KB
| article about porting to Win32 that accompanied one
| particular Windows 3.1-era Microsoft compiler[3].
|
| If you want to learn DCOM95-vintage COM, you need to read
| Box and Brockschmidt and that _COM Programmer's Cookbook_
| [4] thing that was somebody's own private initiative
| inside Microsoft and is buried somewhere in the technotes
| and _then_ the COM Specification will be accessible to
| you, and _only after that_ will the MSDN specification
| make some sort of sense. If you want to learn the how or
| why of COM marshalling in particular, you will perhaps be
| helped by some of the above, but really you need to
| invent a time machine and read a series of blog posts
| Raymond Chen wrote in _2022_ [5]. Only then will the MSDN
| reference be even slightly helpful (and even then not
| that much over the IntelliSense hints).
|
| If you want to learn ActiveX ... I have no idea what you
| need to read!
|
| If you want to learn MSMQ/MTS/COM+/whatever, you need to
| read that one book[6] that's still going to leave you
| with more questions than answers, and then maybe track
| down some MSJ articles from after COM+ was only a vague
| marketing term for something internal, but before .NET
| completely overtook all Microsoft communications
| channels. If you want to learn about using COM contexts,
| first, my condolences, second, AFAIK your _only_ source
| for this Win2K-era, and I quote, "backdoor into the very
| low-level COM infrastructure", is Raymond Chen's post
| from two decades later[7]. There's no motivating spec for
| any of this, even one as scarce on details as the later
| parts of the COM one.
|
| If you want to learn about WinRT internals, well, there
| are some blog posts random people on the Internet have
| written[8], and maybe you can spelunk some in the
| Win8-era legacy MSDN docs that are somewhat more explicit
| about what's happening. If you want to learn about
| WinRT's headline feature of "metadata-driven
| marshalling", _fuck you_ , it's not explained anywhere,
| nor is an up-to-date MIDL grammar that would include the
| ways to adjust it a "priority" for that team--or maybe
| it's just that I don't have a time machine, but Raymond
| Chen is mortal too, and it's been over a decade.
|
| And it's all like that.
|
| Again, if you were there at the time and you subscribed
| to MSDN, until 2005 or so I think you would've gotten
| basically all of the things I listed on the CDs, and more
| besides (Dr. GUI and Dr. International anyone?). But if
| you only joined in 1995 or 1998 or 2000, God help you.
| (WinRT happened after 2005, though, so the sum total of
| in-depth, under-the-hood narrative stuff about it is fuck
| all.) The references from that era are excellent, but as
| far as, again, narrative docs are concerned-- C'mon,
| guys, you had _Ted Chiang_ at your disposal and that's
| what you managed?..
|
| (Then again, it probably had very little to do with the
| technical writers themselves and a lot to with the
| preposterously hectic development and a management
| culture that just did not prioritize this sort of thing.
| But still.)
|
| [1] http://web.archive.org/web/20231204102018/https://byt
| epointe... (wait, has bytepointer.com died? that would
| make me very sad...)
|
| [2] https://openlibrary.org/works/OL9256722W/The_old_new_
| thing
|
| [3] Nope, can't find it right now! Good thing Microsoft
| deleted most of the old KB articles from their website...
|
| [4] https://learn.microsoft.com/en-us/previous-
| versions/ms809982...
|
| [5] https://devblogs.microsoft.com/oldnewthing/20220615-0
| 0/?p=10...
|
| [6] https://thrysoee.dk/InsideCOM+/
|
| [7] https://devblogs.microsoft.com/oldnewthing/20191128-0
| 0/?p=10...
|
| [8] https://www.interact-
| sw.co.uk/iangblog/2011/09/25/native-win...
| bsder wrote:
| You are seeing a creation date bias. And it doesn't help that
| there just aren't that many systems programming languages.
|
| Until Rust in 2010, there basically was almost no motion in the
| "system programming space". Even afterward, there needs to be
| enough uptake to actually have critical mass. Only then can
| people start using it for projects.
|
| Side note: D actually predates a lot of this by being from
| 2001, but, sadly, never seemed to get any traction. It seems
| like it had the misfortune of being about 10 years too early
| and that programmers just weren't ready for a new systems
| programming language at that point.
| mrbluecoat wrote:
| Are ARM and RISC supported or are the errors on
| https://builds.managarm.org placeholder stubs?
| no92 wrote:
| The ARM and RISC-V ports are in different states of being a
| work-in-progress.
| ironhaven wrote:
| The hubris of calling your operating system pragmatic
| mananaysiempre wrote:
| Your _microkernel_. I expect the intended point of comparison
| was "principled and pure", not "unsuitable for general use".
| ArsenArsen wrote:
| WDYM? 'pragmatic' here means 'not necessarily purely
| microkernel-y if very difficult'. for instance, the memory
| manager is in the kernel in managarm
| ecjhdnc2025 wrote:
| But this "not necessarily purely microkernel-y if very
| difficult" interpretation essentially means that Windows NT
| is pragmatic.
|
| Because this is pretty much exactly how NT came to be the
| mess it now is.
|
| I wonder if the parent commenter's point is that really,
| almost any OS design can be called "pragmatic", and therefore
| stressing it is particularly prideful.
| netbsdusers wrote:
| NT is no microkernel, nor has it ever been. It has always
| been monolithic.
| ecjhdnc2025 wrote:
| You are perhaps missing the point of what I am saying.
|
| But anyway: around the introduction of NT [0] there was
| clear discussion about how the kernel design was informed
| by the Mach/kernel boundary.
|
| https://en.wikipedia.org/wiki/Windows_NT
|
| _" Like VMS,[24] Windows NT's kernel mode code
| distinguishes between the "kernel", whose primary purpose
| is to implement processor- and architecture-dependent
| functions, and the "executive". This was designed as a
| modified microkernel, as the Windows NT kernel was
| influenced by the Mach microkernel developed by Richard
| Rashid at Carnegie Mellon University,[26] but does not
| meet all of the criteria of a pure microkernel."_
|
| https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#
| Hyb...
|
| _[...] the strict distinction between Executive and
| Kernel is the most prominent remnant of the original
| microkernel design, and historical design documentation
| consistently refers to the kernel component as "the
| microkernel"._
|
| [0] which I am old enough to remember as an adult and a
| graduate -- I remember particular criticism from
| academics in OS design around the time of NT 4.0, which
| as I (admittedly hazily) recall relaxed some of the
| distinctive design because 3.5's graphics performance was
| too poor and the graphics subsystem had to be moved
| essentially into the kernel.
| tomcam wrote:
| Please elaborate
| bobnamob wrote:
| Doesn't pragmatic just mean that you've knowingly made some
| tradeoffs that go against the ideal?
|
| Admitting that doesn't read like hubris to me
| dang wrote:
| Apparently very little past discussion:
|
| _Managarm: August 2022 Update_ -
| https://news.ycombinator.com/item?id=32515546 - Aug 2022 (3
| comments)
|
| _The Managarm Operating System_ -
| https://news.ycombinator.com/item?id=24689727 - Oct 2020 (1
| comment)
| tomcam wrote:
| Very neat project! It appears to run on qemu. Can someone tell me
| at the 30,000' view what's required to get it running on actual
| hardware? I'm imagining something like signed boot manager, hard
| disk drivers, etc. They seem to have a ton of USB stuff working
| which seems amazing to me, but I've been out of the low-level PC
| loop for a couple decades and don't know what prevents working on
| bare metal in 2024.
| boricj wrote:
| At 30,000' I'm not seeing anything that would prevent this from
| booting on hardware. It seems to have a reasonable complement
| of modern, real-world drivers. On the other hand, physical
| hardware tends to have bugs, quirks and diversity that VMs
| don't have, so hobby operating systems may have trouble with it
| if they aren't tested on it.
| dilippkumar wrote:
| This is mostly a note to myself.
|
| It's interesting to consider "what next" once an OS project
| reaches this stage. There are soo many directions a team can
| take, but also, none of those direction lead to a clear path
| towards massive user adoption.
|
| There are obvious holes/gaps in what mainstream OSes offer today,
| however it is not clear how a project goes from here to
| addressing those gaps, and even if those were to be addressed, it
| is not clear how it could displace mainstream OSes.
|
| We are clearly better off having projects like this, that give us
| options in case something were to go horribly wrong with
| mainstream OSes. However, what is the incentive to keep projects
| like this alive when the path ahead is soo unclear?
|
| How does one disrupt the operating systems market?
___________________________________________________________________
(page generated 2024-07-27 23:00 UTC)