I don't mind where a Rust port to Hurd is discussed. To get some of the technical answers regarding Rust though you may need to ask on reddit.com or maybe the rust-...@mozilla.org. Although I will research what I can. I'm not a language developer myself.
I'm not a student so I can't participate in the GSOC myself. As I understand it anyone can suggest a project though. I am willing to begin with investigating a port of Rust, with your help. >Please verify (or ask us to help looking at the Rust sources if you're >unsure): it does have a functional x86 (that is, 32-bit) GNU/Linux >port, which generally is implemented on top of the usual Unix/POSIX as >well as glibc APIs (»#define _GNU_SOURCE«), and makes little or no use >of direct Linux kernel syscalls (such as futex, for example). I will investigate further. I have to reinstall Linux and get the Rust source as I can't find a way with github web service to searching inside source. >> no null or dangling pointers, no buffer overflows >How is this implemented? Internal reference counting, or garbage >collection? If the latter, which engine? "The safe pointer types are @T, for managed boxes allocated on the local heap, ~T, for uniquely-owned boxes allocated on the exchange heap, and &T, for borrowed pointers, which may point to any memory, and whose lifetimes are governed by the call stack. Currently, the Rust compiler generates code to reclaim managed boxes through reference counting and a cycle collector, but we will switch to a tracing garbage collector eventually." See below for link to details about future garbage collector design. >> lightweight tasks with message passing, no shared memory >How implemented? Standard pthread interfaces or some internal thing (using >which kernel interface)? "bblum at andrew.cmu.edu This summer I worked on Rust's concurrency/parallelism libraries (The underlying concurrency primitives - semaphores, mutexes, rwlocks, condvars - can also be used directly, in std::sync, in case you have some state external to rust that needs to be protected, such as when linking to a C library or using the filesystem. These should be preferred over the pthread ones because these are rust-scheduler- aware; i.e., other rust tasks can be scheduled on your CPU while you are blocked on one of these.)" Ben probably knows the answer. >> Exception handling >> unrecoverable unwinding with task isolation >Requiring run-time/operating system support, or based on standard DWARF? To be investigated. >Aha, garbage collection. How implemented/which engine? (Boehm?) https://github.com/elliottslaughter/rust-gc-talk >More specifically, how do you get from Rust source code to executing machine >code? ... >What is your expertise as a Rust programmer (using Rust), Rust >developer (developing Rust itself), and programming language >implementation generally, focussing not on the computer science part of it >;-) but on the actual implementation, host system interfaces, and so on? I'm a new Rust programmer/developer wanting to write OS components in Rust and contribute to porting Rust to Hurd and extending Hurd. See my contribution regarding writing a virtual file system translator and implementing a missing Rust library via a layer at the same time. >In the following the terminology is sometimes unclear (maybe this simply is >"new ground" > for you?), for example, often when you say »kernel« that should -- in >our terminology -- be »operating system«; by kernel we normally >understand the GNU Mach microkernel, the base of the operating system. >What experience do you have with operating system implementation? I would have liked more time to get up to speed with Hurd but the subject of GSOC came up on both this and the Rust forum and I wanted to post while it was relevant. You have to remember that most of that post was meant for the Rust list. I am reasonably new to well layered modern kernels and the concept of microkernels. It's mainly a terminology issue. I understand, at least what I said in my post, I just can't articulate it using the correct terminology currently. See what I said above regarding to being forced into posting prematurely posting as GSOC was in discussion. >Implementing device drivers in Rust is yet another project. Generally >(due to the complexity and sheer number of drivers), the tendency has >been in "use" another operating system's drivers (such as Linux') by >implementing some sort of glue-code to embed and run them. > But of course, once the RPC interfaces are available in the Rust >language/libraries, it would be possible to implement device drivers, too. I had assumed that because a layer for network card was required that each category of driver would need layering and so suggesting there would be a demand for new drivers to be written in, potentially a new language. That would offer vast driver support If Linux drivers can be used. >> Even if having the majority of drivers written in Rust is optimistic >> the above two paragraphs still suggest the advantages of Rust >> language bindings for GNU Hurd such as being able to write a >> currently functioning microkernel in the Rust language with all the >> benefits that implies for both Rust programmers and the GNU Hurd microkernel. >Again, you don't want to rewrite the GNU Mach microkernel in Rust, but >rather implement operating system components in Rust, that make use of >the microkernel's interfaces. (Of course, the microkernel could be >rewritten, too, but that is yet another project, and much bigger one. I was opening up a potential avenue for the small number of Rust developers that would like to write a Rust operating system to work on Hurd, instead of starting from scratch. >Samuel Thibault wrote >Well, porting Rust to GNU/Hurd definitely can be useful, so your >project is more than welcome in that regard. Good. It would certainly encourage me to develop on Hurd. >Samuel Thibault wrote >I however have to say you probably underestimate the amount of work >needed to write a driver. The language can help in some way, but not >very much. The main part of difficulty is to manage to understand how >the device really works, and devise something that works with it. We >don't really want to spend time on this, and rather use a maintained >layer like DDE. If you will be able to use Linux drivers, perfect. I was under the impression that rewrites were required.
