
Redox: A Rust Operating System - mfincham
https://github.com/jackpot51/redox
======
acconsta
I know this is a young project, but right now it looks like a terrible waste
of Rust's features. Raw pointers everywhere, most allocations unchecked, and
_264_ unsafes in just the kernel.

 _unsafe_ is a necessary escape hatch, but the temptation to use it to write
C-style code is strong.

~~~
jackpot51
Hello, I wrote Redox, and I completely agree. I have been doing pretty
substantial cleanups in this manner recently. At first, I had to start with
pretty nasty code to get things going. Within the last week, I seperated out
fundamental applications and moved them to the filesystem. This also meant
writing a syscall interface, which is currently compatible with Linux system
calls. Unsafe is often necessary in kernel land, and I am always rewriting
code to make its use span smaller scopes.

~~~
acconsta
Hello! I think it's possible to encapsulate unsafe pointer operations so
they're only required in memory allocation, I/O primitives, and device DMA.
I'll open a github issue or two with thoughts.

Out of curiosity, are you modeling this on an existing code base/architecture,
or is this a new design?

~~~
jackpot51
This is a new design, but the syscall interface is like Linux, the
read/write/open/close/ syscalls are the same ABI.

As for unsafe, it would be possible to make much less of the kernel unsafe.
The kernel allocation could be exposed in an interface like this:

struct Memory { address: usize }

impl Memory { fn new() -> Option<Memory>; fn realloc(&mut self, size: usize)
-> Option<Memory>; fn size(&self) -> usize }

impl Drop for Memory { fn drop(&mut self) }

PIO could be wrapped up MUCH better:

PIO8, PIO16, and PIO32 could handle inb, inw, ind. A lot of my driver bugs
have come from using the wrong size!

MMIO could be handled similarly.

The PCI driver could give drivers a limited set of PIO and MMIO structs to
operate on

------
k__
Rust really seems like the next step in system programming.

Would it be possible to have this lifetimes/borrowing stuff in a scripting
language?

Like, I care about who owns something, but I don't care about what something
is?

~~~
ionforce
Don't scripting languages typically not exhibit the problems that Rust
attempts to address?

~~~
k__
I had the impression Rust tries to get memory safety without the need/overhead
of GC.

~~~
openasocket
I don't know about the borrowing system, but I believe there are several Lisps
that avoid mark-sweep garbage collection. NewLisp is one such example, though
I think they sidestep the issue by copying everything by default and using
efficient allocation/deallocation.

------
nickpsecurity
The blog was a good read. I agree with acconsta that the description doesn't
seem to utilize Rust's better attributes. Plus, that it's "starting to look
like Linux" (author) may or may not be good. I'd look at Wirth's Oberon or A2
Bluebottle for a simpler start: type-safe, memory-safe (mostly), GC'd OS with
good documentation, source available, and a simplicity focus for easy re-
implementation. Rust, in theory, can do whatever it did and faster.

Additionally, if doing clean-slate, might be worth looking into alternative
models for constructing or securing OS's. EROS security OS, SPIN OS's type-
safe linking for acceleration, Minix 3's reliability scheme, JX OS's
architecture, Microsoft's verified VerveOS scheme, maybe even Amoeba
distributed OS just for kicks to see what it could do today. Lot of stuff that
might be better than Linux model with a Rust implementation in terms of
reliability, security, extensibility, or developer productivity.

Just a thought for Redox author or someone else wanting to try an OS in Rust.
However, best thing to come out of Redox project, imho, isn't the OS so much
as this article:

[https://redox-
os.org/index.php?controller=post&action=view&i...](https://redox-
os.org/index.php?controller=post&action=view&id_post=5)

Great write-up on an equally great strategy of developing with hardware that's
well-supported by both native OS's and virtualization. That's worth copying
and expanding in other projects. Maybe worth a dedicated list like the HCL's
where there's a list of computer builds that are easiest to develop on with or
without virtualization. Or list it one piece of hardware at a time.

~~~
jackpot51
That was so good I put it on the blog!

~~~
nickpsecurity
Didn't see that coming haha. Glad you liked it. At 135pts & front page, you
apparently are cool enough for Hacker News. Probably a cool project in a HN-
favorite language led to this. ;)

------
jackpot51
I am Jackpot51, I wrote Redox and would be able to confirm with a master push.

To start, this wasn't supposed to be public yet. I was preparing cleanup
before release, and I hope it is not seen as complete.

I am excited to see how much attention this has gotten, and I would be willing
to answer any questions about Redox, how to use it, and how to contribute.

I have a blog at [https://redox-os.org/](https://redox-os.org/) where I
recently posted screenshots.

We can IRC at irc.mozilla.org #redox

------
noja
"Redox is not correct, secure, or documented. It does a lot of things in a
cavalier, leave it up to the application, manner. Applications can malloc and
forget to free, Redox will not clean this up. Applications can access missing
memory or kernel memory, Redox does not care. All applications run in Ring 0,
and have all permissions. Some syscalls use vtables that rely on exactly the
same struct defintions in userspace as kernel space. Syscalls cannot return
values, except by writing them into a passed pointer. Memory allocation is
done in the application, and uses a global memory allocation table that
applications directly modify. None of its functionality is documented, outside
of example source files." \-- [https://redox-os.org/](https://redox-os.org/)

Yikes!!!

~~~
poelzi
OS development takes time and he clearly states this will change, criticizing
such a young project with halfquotes is unfair and discouraging for the
developers. shame on you.

I'm waiting for OS development to start up in rust as it is clearly the better
choice then C/C++ for a kernel.

~~~
d9fb698e010974b
How easy is it to deal with raw memory in rust? That's the main reason for
using C in my opinion.

~~~
Jhsto
Not sure is it like this anymore, but might be worth giving a read:

> But allocating memory seemed like a fun exercise. To allocate something on
> the heap in Rust, you can do

> let a = ~2

> This creates a pointer to a 2 on the heap.

[http://jvns.ca/blog/2014/03/12/the-rust-os-
story/](http://jvns.ca/blog/2014/03/12/the-rust-os-story/)

~~~
zcdziura
That syntax has been changed, actually. Now, to allocated an owned pointer
allocated on the heap, you use the Box type:

> let a = Box::new(2);

I believe it's an unstable feature currently to use the "box" keyword to heap-
allocate a value, which can also be used in pattern matching. I saw somewhere
that "box" will be made into an overloadable operator, such that you can
easily create reference-counted and atomically reference-counted types.

~~~
steveklabnik
Yes, that's generally correct. We still haven't fully decided on the exact
syntax. If anyone wants to get involved, this RFC was the one that got merged,
but hasn't been made stable yet: [https://github.com/rust-
lang/rfcs/blob/master/text/0809-box-...](https://github.com/rust-
lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md)

And this is the active, in-final-comment-period one which modifies it:
[https://github.com/rust-lang/rfcs/pull/1228](https://github.com/rust-
lang/rfcs/pull/1228)

------
Jhsto
I do not understand much about low level languages or operating systems, but
could someone explain why does this project need C in its codebase?

~~~
eximius
Disclaimer: haven't had time to read the code yet.

It is probably easier to do all of the massively unsafe things required to
initialize in C than it is in Rust. Then Rust is just used after C does its
dirty things.

~~~
Hemospectrum
That shouldn't ever be necessary. Part of the point of Rust is that you _can_
do unsafe low-level work, so long as you tag it with the "unsafe" keyword to
enable pointer arithmetic and so forth.

------
talles
> Redox is a Rust based operating system, designed to be modular and well
> documented.

How does one _design_ something to be well documented?

~~~
steveklabnik
Well, depending on your definition of "Design", you do things like

    
    
      1. Ensure you have the tooling to produce nice docs.
      2. Build time to write docs into your planning.
      3. Actively try to find people who will write good docs.
      4. Focus on making your code understandable, so that the
         eventual docs will make sense. Spaghetti code is hard
         to document.

~~~
talles
(IMO) that is taking documentation in consideration while designing, and not
_designing to_ (it's not the actual purpose of the design).

Pedantism aside, I guess it was a phrasing issue.

------
brianclements
Can someone clarify, but it looks like it's going to be a monolithic approach
here correct?

~~~
acconsta
In the current Redox design, _everything_ runs in privileged mode, so it's
kind of the ultimate monolith?

~~~
brianclements
I kinda got that from the blog, but I guess I was more curious if anyone got a
whiff of longer term design goals and if that was where things were headed.

------
cgh
Judging by the syscall implementation, seems to be 32 bit only? Apologies if I
missed something in the docs, such as they are.

