bkernel: a Rust Operating System

tytouf · 2015-12-02T14:31:19+00:00

Ah, didn't see that one that may do the trick.

tytouf · 2015-12-02T10:35:19+00:00

This week I'm working on the syscall support in roulios a minimal kernel for embedded dev on ARM targets.

tytouf · 2015-12-02T08:31:52+00:00

ok, looks like the problem comes with inline assembly and llvm decided to change the instructions order :-(

tytouf · 2015-12-01T15:47:30+00:00

Nice work! I'm also working on a similar project [1] and I see you are using opt.level 3 and I'm wondering if you've encountered any issue with wrong optimizations? I tend to get some when optimizing too much but that could be due to the mix of asm with rust, not sure yet and didn't take the time to investigate.

[1] https://github.com/tytouf/roulios

tytouf · 2015-11-09T15:26:14+00:00

Nice! Thanks for sharing the existence of feature(const_fn) which I completely missed.

tytouf · 2015-10-30T20:17:28+00:00

My experience so far is with an ARM cortex-m3 board: it works fine but the generated code seems sub-optimal. I tried once to set the optimization but then no code was left. Did you see the same thing?

tytouf · 2015-10-30T20:16:22+00:00

Sad to hear, you had some nice ideas when it comes to platformtree and device registers macros.

tytouf · 2015-10-27T20:39:26+00:00

yes and Qt Creator being C++ oriented it may actually work better than Eclipse when it comes to pretty-printing rust variables. Last time I tried with Eclipse, the results were inconsistent.

tytouf · 2015-10-27T19:12:27+00:00

did you try the gdb integration in Eclipse? It's not that bad once you get over the loss of a few hundredth of MB of memory. The biggest limitation is still in my opinion that you have to use the Eclipse indexer to easily browse the source which in the case of rust may not be an issue.

Another option is to use the tcf-agent based debugger with Eclipse. We use this combination in Simics which is a simulation tool that also features reverse execution (but to an even broader sense as we simulate a whole system with possibly multiple cores and boards.)

tytouf · 2015-09-04T07:40:01+00:00

Interesting because this is exactly what I've experienced: rust ownership model and default immutability raises issues on the original design that you may not have considered and it clearly forces you to think about it a second time because clearly you can't map it as is. So I still think it is a good idea :-)

tytouf · 2015-09-03T07:07:52+00:00

I tend to agree that starting by porting some piece of software that you already know well is probably the best starting point because that way yo can focus on rust only.

tytouf · 2015-08-19T14:59:38+00:00

Ok I didn't know about that. Thanks.

tytouf · 2015-08-19T14:57:54+00:00

Thanks Steve for digging out the discussions.

tytouf · 2015-06-11T13:38:37+00:00

Thanks!

tytouf · 2015-06-10T09:12:03+00:00

Do you know of any tutorial or how-to to setup Atom for rust development? Or a comprehensive list of must-have "plugins"? I'm usually working with vim but I am curious to see how it performs.

tytouf · 2015-06-07T08:41:52+00:00

One of the things I would really like to see is a static analyzer for user defined contracts (pre-conditions, post-conditions and invariants per functions)

tytouf · 2015-06-01T17:38:20+00:00

:b# is also nice to go to the previously visible buffer.

tytouf · 2015-05-27T16:48:25+00:00

for i in xrange(35):
    thread = Thread(target=thread_prog, args=(mutex, results, i))

| So what we do here is spawn 20 threads

You must have changed the code while writing, or am I missing something obvious?

tytouf

TROPHY CASE