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

[Thomas Schwinge]

Hi!

On Thu, 14 Feb 2013 15:26:46 +1300, "Nolan Tunnicliffe" <nolan@2ndnature.co.nz> 
wrote:
> http://www.reddit.com/r/rust/comments/18dfd6/gsoc_2013_started_any_rust_project_ideas/

Thanks for this proposal (the very first we (GNU Hurd) get this year)!
Looks like a good project to me.

As you posted it on <bug-hurd@gnu.org>, I'll assume you'd like it
discussed there.  I'd also be fine posting/subscribing to a Rust mailing
list.  [Well, in fact I simply cross-posted the email there (and tried
subscribing, which currently doesn't seem to work, though); please keep
everyone in copy.]  Reddit would be an unusual place (for us, at least)
to discuss technical topics.


Many of my following questions may already be answered in the regular
Rust documentation -- which I have not yet had the chance to chase up.
Of course it is fine to simply give pointers that answer my questions.

> Rust is a language sponsored by Mozilla who are using it to write a next
> generation web browser engine. It is low level hardware access capable,
> making it a potential replacement for C and C++ for writing device drivers.

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).

> From http://www.rust-lang.org/ :
> 
> Rust is a curly-brace, block-structured expression language. It visually
> resembles the C language family, but differs significantly in syntactic and
> semantic details. Its design is oriented toward concerns of "programming in
> the large", that is, of creating and maintaining boundaries - both abstract
> and operational - that preserve large-system integrity, availability and
> concurrency. 
> 
> It supports a mixture of imperative procedural, concurrent actor,
> object-oriented and pure functional styles. Rust also supports generic
> programming and metaprogramming, in both static and dynamic styles. 

Look, it has *all of it*!  ;-)

> Memory safety
> 
> no null or dangling pointers, no buffer overflows

How is this implemented?  Internal reference counting, or garbage
collection?  If the latter, which engine?

> Concurrency
> 
> lightweight tasks with message passing, no shared memory

How implemented?  Standard pthread interfaces or some internal thing
(using which kernel interface)?

> Exception handling
> 
> unrecoverable unwinding with task isolation

Requiring run-time/operating system support, or based on standard DWARF?

> Memory model
> 
> optional task-local GC, safe pointer types with region analysis

Aha, garbage collection.  How implemented/which engine?  (Boehm?)

> Compilation model
> 
> ahead-of-time, C/C++ compatible

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 copmuter science part of it ;-) but on
the actual implementation, host system interfaces, and so on?


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?

(These questions, by the way, are just so that we get a feeling about
what we can roughly expect you to know, and what we first have to teach
you -- but no problem with that, of course!)

> For the Google Summer of Code 2013, Port the Mozilla Rust
> http://www.rust-lang.org/ programming language to GNU Hurd, Mach based
> operating system microkernel. GNU Hurd microkernel allows any language that
> can RPC Remote Procedure Call http://www.gnu.org/software/hurd/hurd/rpc.html
> to write kernel 'servers' ie. components of the kernel that in Mach's case
> run in User mode as opposed to Kernel mode. Allowing an existing modern
> functioning kernel to be written, extended and potentially parts rewritten
> in Rust. Kernel writers would use a modern low level capable language, Rust,
> to extend a functioning kernel and components in a language that was
> designed to preserve large-system integrity, availability and concurrency,
> some of the same goals of GNU Hurd project itself.

This in fact is a separate project, which first requires a general port
of the Rust programming environment to GNU/Hurd, which I cannot judge yet
how difficult it will be.  But of course it (enabling Hurd interfaces
(RPCs) in Rust) is a very desirable follow-on project!

> GNU Hurd allows runtime installation of user mode, and most are, kernel
> components that do not require root access or a reboot to install and if
> they crash do not bring the whole kernel down. Unlike most UNIX's, GNU Hurd
> is designed to be modified and extended through system hooks. The kernel can
> be developed and progress at a potentially different pace compared to Linux.
> A lot of functionality is implemented as file system interfaces
> 'translators' which may be another way of providing further features to Rust
> without reprioritizing language features such as httpfs virtual filesystem
> and netio http://www.gnu.org/software/hurd/hurd/translator.html . Perhaps
> Hurd translators or Rust library features can be written with a layer such
> that you can add the feature to a GNU Hurd virtual file system 'translator'
> AND Rust library with a single implementation. Work on either is work on
> both.

> Potentially this could mean that one missing aspect of GNU Hurd, drivers,
> could be written in Rust with the advantage that they are written in a
> modern language, for making the sacrifice of having to rewrite drivers to
> work on this kernel as opposed to sticking with existing drivers written in
> 'C' and Linux. Turning the disadvantage in the lack of drivers currently
> written for Hurd into an advantage that they could now be written in a new
> language, Rust. Making the assumption that hardware device drivers can
> currently be written for GNU Hurd in any language that can RPC and has low
> level hardware access capability. I believe the project to make userspace
> drivers exists if not yet fully realized.

Yes, the DDE project, <http://www.gnu.org/software/hurd/dde.html>.

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.

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


Grüße,
 Thomas

pgpnJEJR2S_HB.pgp
Description: PGP signature