RE: [Google Summer of Code 2013] - Mozilla Rust language bindings

[Nolan Tunnicliffe]

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-dev@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.