Speculative: Rust for base system components

[Damjan Jovanovic]

Kernel modules in Rust might benefit from the better type checking and thus
less memory leaks, less memory corruption, etc. but they are usually small
anyway so it's probably not worth it.

The bigger benefit of running Java applications (not device drivers) in the
kernel is performance. If applications run in kernel mode, context
switching between kernel threads is much faster than user threads, system
calls just become function calls, etc. Unlike C, Java can be sandboxed (at
least in theory), and lack of native pointers and memory safety ensure it
cannot access hardware directly anyway, so the rest of the system is still
protected. Around 2005, Microsoft Research made Singularity OS, which used
such techniques to run safely C# applications in the kernel, and it was
about 20% faster than C in user space.

On Tue, Jan 1, 2019 at 6:59 AM Cy Schubert <Cy.Schubert at cschubert.com>
wrote:

> What would having another language in base buy us? This reminds me of a
> couple of months ago at OpenHack Victoria someone was trying to convince me
> that the kernel needed a JavaVM. (Sure we each had a few beers) but the
> similarity of this discussion doesn't escape me. Kernel modules and
> functions written in java^H^H^H^H rust: why?
>
> ---
> Sent using a tiny phone keyboard.
> Apologies for any typos and autocorrect.
> Also, this old phone only supports top post. Apologies.
>
> Cy Schubert
> <Cy.Schubert at cschubert.com> or <cy at freebsd.org>
> The need of the many outweighs the greed of the few.
> ---
>
> -----Original Message-----
> From: Peter Jeremy
> Sent: 31/12/2018 18:48
> To: Igor Mozolevsky
> Cc: Hackers freeBSD
> Subject: Re: Speculative: Rust for base system components
>
> On 2019-Jan-01 00:53:48 +0000, Igor Mozolevsky <igor at hybrid-lab.co.uk>
> wrote:
> >Quite frankly the compile time isn't really *that* important,
>
> I disagree.  FreeBSD seems to be heading back to the batch days - you
> submit your buildworld request and come back tomorrow to see if it worked.
> That is a significant hinderance to development and, based on various
> mailing list comments, is causing breakage because developers are cutting
> corners due to the pain involved in running "make universe" before they
> make a large change.
>
> >longer (if not much longer) build times might push toward a better
> >modularisation and compartmentalisation of the OS and the kernel so a
> >small change in the kernel, for example, doesn't require the
> >recompilation of the whole damn thing when nothing else is affected.
>
> Two problems here:
> 1) make doesn't seem to be sufficient to correctly describe a dependency
> tree to allow incremental/partial builds (at, everyone I'm aware of who
> has a successful incremental build system has started by migrating off
> make).  This means that a significant part of the work will be re-writing
> the FreeBSD build system into something else like (eg) Bazel.
> 2) The bottleneck very quickly turns into the linker.
>
> --
> Peter Jeremy
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>