Nothing like finally grokking a major part of the CS operating systems curriculum. Wonderful write up
Writing an OS in Rust: Introduction to Paging
71–80 of 81 posts
Re: Writing an OS in Rust: Introduction to Paging
#72I'm a few surprised nobody have mentioned UlixOS [1]. I'm reading their book, it is just great on many aspects, although it rushes to explain other things that should be detailed a bit more. The chapter about paging is very explicative too.
Re: Writing an OS in Rust: Introduction to Paging
#73Earlier quoted context omitted.
It's been a while since I've looked into it so I hope I won't be too far off the mark: - Regarding high impedance it might be relevant if you want to explain how the controller and memory card interface works, and why you read full 1s when nothing is connected (high impedance line with a pull-up resistor). More generally the issue will crop up every time you have an interface that might be floating, I think people wh…
It's conceivable that metastability issues could be used as a part of copy protection. Well, protection against emulation more like. Of course it's not the smartest choice for that purpose, because there might be chip-to-chip differences. And environmental factors like temperature could affect it as well. But who knows what people wrote after Bleem PS1 emulator was public? So have metastability issues (or other HW bu…
Most (all?) copy-protection schemes on the PSX had to do with the CD subsystem. I think they were mainly attempting to defeat hardware "modchips" used to play non-original copies of games. Obviously those are trivial to bypass in an emulator.
I'm not aware of any copy-protection scheme on the console that would target specifically emulators. I guess Bleem was not big enough a threat to warrant specific protections?
Besides I expect that Bleem, in order to run full speed on the underpowered hardware of the time, must have had terrible accuracy and therefore must have employed a wealth of game-specific hacks to get around issues. As such I expect that if they had decided to emulate your game they wouldn't have had too many issues reverse-engineering any trivial metastability-detecting code to implement an ad-hoc hack.
Re: Writing an OS in Rust: Introduction to Paging
#74Earlier quoted context omitted.
That's not possible to do safely for arbitrary data structures because they can contain pointers or references. If you reload to a different address then the pointers, even within the allocated chunk, would be invalid and require fixup. And if you require fixup then you might as well do (de)serialization for your data structures. Just allocating into such a memory region (essentially custom page swapping) will eventu…
Perhaps this problem can be overcome by modifying the concept of a pointer slightly, to make it a "based pointer" (?) I found an old discussion on this topic here: https://news.ycombinator.com/item?id=13890011 Note that the Microsoft C++ compiler implements based pointers, using the __based keyword.
Specialized data structures can be built that contain primitives and other types supporting this kind of thing. But you still can't store arbitrary data because they could contain FFI pointers, handles to native resources, things that need to run destructors etc.
So to do this safely all the types must be whitelisted through a custom trait. Copy is close, but not quite, since references are still Copy.
Re: Writing an OS in Rust: Introduction to Paging
#75Earlier quoted context omitted.
Get used to the idea that embedded is 15 years behind PC. Which is initially frustrating but if you step back is kind of a good thing. I’d also like to see Rust make it’s way into embedded. C support for things like data serialization or RPC for interfacing to web stuff is limited, people just don’t port it to C. And C++ doesn’t thrill me in terms of its non-deterministic garbage handling and difficult to debug natur…
C++ has deterministic garbage collection.
C++ does not have garbage collection of any sorts. Objects leave the scope and are destroyed, however the order in which they are destroyed is not defined by the standard.
Re: Writing an OS in Rust: Introduction to Paging
#76I've followed Phil's site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I've tried learning more about writing operating systems via resources like the OSdev wiki, but much of its material almost seems to discourage working on an OS of any kind unless you're already sure of what you're doing. Phil's articles seems so much more a…
I think it's one of these things that's more approachable if you start by working on specific subsystems of an existing OS. This way you don't have to figure everything out at once. At least that's how I did it. I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It's a bit as if a painter was saying "It tried looking up guides o…
That's why it's important to choose simpler systems. I've been having fun writing a Forth-based Z80 operating system for the TI-84+ calculator[1]. There isn't too many moving parts and there are many "toy" systems to learn from such as one that boots up to a smiley face[2]. It's all about choice of architecture.
[1] https://github.com/siraben/zkeme80 [2] https://www.ticalc.org/archives/files/fileinfo/442/44227.htm...
Re: Writing an OS in Rust: Introduction to Paging
#77I've followed Phil's site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I've tried learning more about writing operating systems via resources like the OSdev wiki, but much of its material almost seems to discourage working on an OS of any kind unless you're already sure of what you're doing. Phil's articles seems so much more a…
I think it's one of these things that's more approachable if you start by working on specific subsystems of an existing OS. This way you don't have to figure everything out at once. At least that's how I did it. I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It's a bit as if a painter was saying "It tried looking up guides o…
> I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible
I actually learned C by writing an OS from ages 16 to 18. I don't know if I'd recommend it to everyone, but it is surprisingly accessible if you limit scope. The real hard parts are dealing with complicated hardware. If you care about the basics like keyboard, mouse, display, flat memory, no threads, then its incredibly easy in 16bit C for x86. 32bit C (i386) is also easy, but does require a bit more setup etc.
It is incredibly educational learning how to write your own libc and having to manage toolchains etc. You very quickly learn the exact boundaries of what is computer controlled and what is toolchain controlled, and of course what is controlled by your own code.
And yes, I had a similar experience to you re: emulators. Tried making a simple 8086 computer emulator. CPU instructions are really easy and really the part I enjoyed. Emulating the hardware and all the machine protocols gets very difficult and complicated very quickly. I ended up, after a few months of that, rescoping the project to only be an 8086 CPU emulator, which was one of the few projects of my youth I actually completed.
Re: Writing an OS in Rust: Introduction to Paging
#78I've followed Phil's site on making an operating system. Ever since having worked on PintOS in college, operating systems and their internals have fascinated me. I've tried learning more about writing operating systems via resources like the OSdev wiki, but much of its material almost seems to discourage working on an OS of any kind unless you're already sure of what you're doing. Phil's articles seems so much more a…
I think it's one of these things that's more approachable if you start by working on specific subsystems of an existing OS. This way you don't have to figure everything out at once. At least that's how I did it. I think writing an OS from scratch is discouraging and not very accessible because... writing an OS is discouraging and not very accessible. It's a bit as if a painter was saying "It tried looking up guides o…
This would make sense....if existing OSes were very good at maintaining non-leaky abstractions. As it stands, one would have to learn tons of stuff unrelated to the task at hand, on top of all the legacy cruft that usually comes with the hardware itself.
Re: Writing an OS in Rust: Introduction to Paging
#79Earlier quoted context omitted.
C++ has deterministic garbage collection.
C++ does not have garbage collection of any sorts. Objects leave the scope and are destroyed, however the order in which they are destroyed is not defined by the standard.
C++ has a garbage collection interface API since ISO C++11, it is up to the respective implementation to provide an optional implementation.
Re: Writing an OS in Rust: Introduction to Paging
#80With memory growing arguably beyond what most application workloads really require anyways, and possibly hardware such as Intel Optane, do we still need things like VM, paging, and segmentation?
>do we still need things like VM, paging, and segmentation? Yes. To begin with, on modern processors, paging is tied with the memory protection system. Memory is protected on a per-page basis. Memory mapped files are implemented through paging. There's also backwards compatibility. Virtual memory allows 32-bit applications to have their physical memory located anywhere. Without that, we'd have to ensure that they res…
I was thinking in terms detached from typical system architecture.
What if we don't tie paging with memory protection when designing CPUs? What if we don't assume, build, or run 32 bit applications? What if we do actually put a hard physical 4GB (or whatever) limit on processes? What if we don't need hypervisors?
What if we trade off hardware and software complexity we've built decades ago for limitations we had decades ago, and build something simpler from scratch?