Operating System Development Tutorials in Rust on the Raspberry Pi(github.com)
github.com
Operating System Development Tutorials in Rust on the Raspberry Pi
https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials
30 comments
What do you think of the notoriously closed/proprietary attitude of Broadcom and the near unavailability of documentation?
I think the standard PC is a far better platform for OS development --- decades of backwards compatibility mean documentation is plentiful, and so is sample code.
I think the standard PC is a far better platform for OS development --- decades of backwards compatibility mean documentation is plentiful, and so is sample code.
Then use a Beaglebone? TI documents everything.
And x86-64 really is a really complex platform to develop from scratch for. Have you seen the C ABI specification for it?
And x86-64 really is a really complex platform to develop from scratch for. Have you seen the C ABI specification for it?
When I did OS development we used MacBooks for x86 development. If a "standard PC" exists the Apple fell far from it, but they have to keep their OS running more than they need to save a buck on the next 10000 units.
I tried really hard to like SerenityOS but I think the decision to make it a UNIX-like POSIX system is a mistake. The POSIX API is outdated and broken in a lot of ways. I wish people would stop making UNIX-like operating systems, we have enough of those to deal with considering just the Linuxes and the BSDs.
> I wish people would stop making UNIX-like operating systems, we have enough of those to deal with considering just the Linuxes and the BSDs.
Your strong opinions on the matter may be warranted from your personal experience, but there is nothing wrong with doing such, there is zero track to you that someone somewhere on this planet is tinkering with an operating system you do not agree with the design decisions of.
> The POSIX API is outdated and broken in a lot of ways.
Curious if you could elaborate your claims. Is it a case of the old APIs must stand (and the baggage therein), or were there some fatal flaws other OS APIs avoided?
Your strong opinions on the matter may be warranted from your personal experience, but there is nothing wrong with doing such, there is zero track to you that someone somewhere on this planet is tinkering with an operating system you do not agree with the design decisions of.
> The POSIX API is outdated and broken in a lot of ways.
Curious if you could elaborate your claims. Is it a case of the old APIs must stand (and the baggage therein), or were there some fatal flaws other OS APIs avoided?
>there is nothing wrong with doing such, there is zero track to you that someone somewhere on this planet is tinkering with an operating system you do not agree with the design decisions of.
I don't understand why you're saying this or what this has to do with my comment at all. I'm a random person on the internet commenting on what I would like to see. You don't have to agree, it's fine for us to feel differently.
>Is it a case of the old APIs must stand (and the baggage therein), or were there some fatal flaws other OS APIs avoided?
I can't really name any POSIX APIs that I think are actually good. In my experience, any real programming for Linux and BSD requires a ton of non-standard non-POSIX APIs anyway. One major problem is: almost all of the core POSIX syscalls are blocking which IMO is really useless for modern programming. Since the past 10 years I haven't used any language runtime that focuses on single-threaded blocking tasks. Everything is about concurrency and async now. Also see this thread for various other problems with it: https://news.ycombinator.com/item?id=27183784
I understand that you or others may want to tinker with this stuff but please consider that an OS designer can be missing some valuable information that could be learned from people with decades of experience deploying these APIs on Linux and BSD and the various other UNIXes. That's the stuff that could save a lot of development time. In my opinion POSIX is really a red herring for OS designers, now the big thing people talk about is "Linux compatibility" which includes a significant number of other things besides POSIX.
I don't understand why you're saying this or what this has to do with my comment at all. I'm a random person on the internet commenting on what I would like to see. You don't have to agree, it's fine for us to feel differently.
>Is it a case of the old APIs must stand (and the baggage therein), or were there some fatal flaws other OS APIs avoided?
I can't really name any POSIX APIs that I think are actually good. In my experience, any real programming for Linux and BSD requires a ton of non-standard non-POSIX APIs anyway. One major problem is: almost all of the core POSIX syscalls are blocking which IMO is really useless for modern programming. Since the past 10 years I haven't used any language runtime that focuses on single-threaded blocking tasks. Everything is about concurrency and async now. Also see this thread for various other problems with it: https://news.ycombinator.com/item?id=27183784
I understand that you or others may want to tinker with this stuff but please consider that an OS designer can be missing some valuable information that could be learned from people with decades of experience deploying these APIs on Linux and BSD and the various other UNIXes. That's the stuff that could save a lot of development time. In my opinion POSIX is really a red herring for OS designers, now the big thing people talk about is "Linux compatibility" which includes a significant number of other things besides POSIX.
I was initially not in the camp POSIX APIs are the devil. I felt there's inherent tradeoffs and design decisions a serious modern operating system seems to need from your comments, but ignoring that, I was suprised that is was a botherance to you?
> we have enough of those to deal
Thanks for sharing some context on why it's bad though. Cheers.
> we have enough of those to deal
Thanks for sharing some context on why it's bad though. Cheers.
This is an excellent textbook on operating system based on Raspberry Pi:
https://www.arm.com/resources/education/books/operating-syst...
https://www.arm.com/resources/education/books/operating-syst...
Tangentially related are there any hobbyist operating systems built on top of the linux kernel, that work radically different from your standard run of the mill OSes like Ubuntu?
NixOS is abnormal, though I don't know if it's hobbyist. But at some level OSes built on the Linux kernel will all have the same "flavor", since the kernel is THE abstraction between hardware and software. So if you want something REALLY radical (I know this is deviating from your original premise), you'll want to look at other kernels. Google's Fuchsia comes mind, as does PhantomOS.
In theory it should be possible to use the Linux kernel and create an OS that doesn't resemble Linux distros like Ubuntu. You could strip out systemd and put in a custom init system that doesn't conform to the typical Unix daemon startup expectations. You could write your own X11/wayland-like display server thing (like Android does). You could replace BASH with some other terminal (even something like PowerShell).
Some things are baked into the kernel and are tricky to work around. Like the execute bit. If you wanted to make a Linux distro that can run arbitrary binaries downloaded from the internet (like Windows) you'll have to contend with the kernel refusing to execute a binary that doesn't have the x bit set at the filesystem level. (Can you even execute files from fat32 or NTFS? Hmmm...)
Another example is the Unix file system layout. If you wanted to show the user a DOS-style drive-based layout (I.E. no /mnt or /bin or /etc, but instead C:\ and D:\) then you have to fork GTK and GNOME to know how to obfuscate the file system like that.
Some things are baked into the kernel and are tricky to work around. Like the execute bit. If you wanted to make a Linux distro that can run arbitrary binaries downloaded from the internet (like Windows) you'll have to contend with the kernel refusing to execute a binary that doesn't have the x bit set at the filesystem level. (Can you even execute files from fat32 or NTFS? Hmmm...)
Another example is the Unix file system layout. If you wanted to show the user a DOS-style drive-based layout (I.E. no /mnt or /bin or /etc, but instead C:\ and D:\) then you have to fork GTK and GNOME to know how to obfuscate the file system like that.
>You could strip out systemd and put in a custom init system that doesn't conform to the typical Unix daemon startup expectations.
I actually don't think you can do this, or would even want to. Systemd doesn't really do anything special beyond putting some tooling around various Linux features. I've seen a lot of other Linux inits and all of them have to conform to those expectations because that is how Unix and Linux are supposed to function, if the init doesn't do those jobs then the system doesn't work.
>You could write your own X11/wayland-like display server thing (like Android does)
Conceptually the Android window system is not really that different from Wayland. X11 is more the outlier. If you're building a new window system, you probably want to do things with a very similar approach to how Wayland and SurfaceFlinger work. No matter what you do there you're going to be constrained by the requirements of getting OpenGL and Vulkan apps to work.
I actually don't think you can do this, or would even want to. Systemd doesn't really do anything special beyond putting some tooling around various Linux features. I've seen a lot of other Linux inits and all of them have to conform to those expectations because that is how Unix and Linux are supposed to function, if the init doesn't do those jobs then the system doesn't work.
>You could write your own X11/wayland-like display server thing (like Android does)
Conceptually the Android window system is not really that different from Wayland. X11 is more the outlier. If you're building a new window system, you probably want to do things with a very similar approach to how Wayland and SurfaceFlinger work. No matter what you do there you're going to be constrained by the requirements of getting OpenGL and Vulkan apps to work.
[deleted]
Absolutely fantastic tutorial, thats going straight to bookmarks.
I hope they can make the Pi boot faster ... It's the one thing keeping the Pi from being useful in most of my embedded projects.
I like to compare it to webpage load time. In the beginning of the web, 5 seconds used to be ok, but nowadays the user wants sub-second load times or they literally walk away. Similarly, devices that don't turn on instantly lose points on UX as well.
I like to compare it to webpage load time. In the beginning of the web, 5 seconds used to be ok, but nowadays the user wants sub-second load times or they literally walk away. Similarly, devices that don't turn on instantly lose points on UX as well.
This isn't really relevant to booting Linux faster because it's about bare-metal programming a toy operating system. More of a learning tutorial than a practical replacement for standard Linux.
There are plenty of guides for speeding up Raspberry Pi Linux boot: http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
If you're developing a true embedded product then you'll be making a customized Linux distribution anyway, which will only include the minimum features needed during boot for your application.
There are plenty of guides for speeding up Raspberry Pi Linux boot: http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
If you're developing a true embedded product then you'll be making a customized Linux distribution anyway, which will only include the minimum features needed during boot for your application.
It honestly sounds like you shouldn't be using a raspberry pi if this level of responsiveness is what you need. Get an ESP32 instead if you want instant response times, or leave the Pi running at all times.
Clearly you're after a suspend/deep sleep mode rather than power-off. Have you looked at the alternatives such as the i.MX family?
I'm not super familiar with RP, what is the typical boot time?
hardware/bootloader stage take around ~2s. After that it's on the OS, a stripped down Linux can get down to also ~2s on top of that if you don't need all the hardware. The more IO you need ready, the longer it takes.
depends on the version of the bootloader and board too. it varies a LOT and often times will sit for over 5 seconds before even starting linux
It depends on who you ask, but usually it's more than 10 seconds, which is too much if you want to embed it into a device that must have an "instantly on" experience.
Even the 4 seconds mentioned by the sibling commenter would be too much (e.g. if a page load of 4 seconds is considered "long", then turning on a device should be shorter as well).
Even the 4 seconds mentioned by the sibling commenter would be too much (e.g. if a page load of 4 seconds is considered "long", then turning on a device should be shorter as well).
I very much doubt another OS on the Pi is going to save you then. (and what the best solution is depends very much on your actual use case and problem)
Don't know if someone in HN have cookie tracking but just a minutes ago I was looking for this
I love the idea of doing more operating system experiments on RPIs just because of the availability & consistency of the platform. You don't have to worry about thousands of drivers for the most part, plus if you're using the RPI 400[1], basically everything is included in the keyboard!
Rust seems like a good way to get people involved as well, because of it's innate following. Excited to give this tutorial a try.
[0] https://github.com/SerenityOS/serenity [1] https://www.raspberrypi.org/products/raspberry-pi-400/