4 ms·

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your l

by dkhenry 13y ago

I am no language designer, but I wonder why use libuv and have to worry about implementing a scheduler and all the other components of a run time loop in your language when the kernel will do this for you. I think it would make more sense to provide a better interface to existing kernel structures then leverage a third party library and then re implement kernel functions around it ( I am mainly thinking about the paragraph about the current scheduler implementation and how basic it is )

pcwalton 13y ago
Three reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.
- jzwinck 13y ago
  Good points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them. Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.
  - oconnor0 13y ago
    And then drivers would be required for each OS creating an additional porting burden.
srisa 13y ago
What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.
- marijn 13y ago
  Look at https://github.com/pcwalton/zero.rs https://github.com/pcwalton/zero.rs . It's not very far yet, but it proves that it is viable to run Rust without a runtime.
  - kibwen 13y ago
    I actually don't think we even need zero.rs anymore. Its purpose was to provide noop implementations for all the "lang items" that the compiler expects to find in the stdlib. However, post-0.7 the compiler no longer requires a lang item to be provided unless you actually use a feature that requires it. For an example, see the code at https://github.com/doublec/rust-from-c-example https://github.com/doublec/rust-from-c-example , which is fully runtimeless.
    - dbaupp 13y ago
      zero.rs (or something like it) is still required, because there's certain lang items that are required/useful (e.g. #[start], destructors, failure, vector bounds checks). (e.g. https://github.com/huonw/rust-malloc/blob/master/zero.rs https://github.com/huonw/rust-malloc/blob/master/zero.rs)
- ldunn 13y ago
  I've done some very preliminary (and bumbling) work with that at https://github.com/ldunn/kern/ https://github.com/ldunn/kern/ It's rudimentary, but it does compile and it does run, and I'm not aware of any particular obstacles to a more featureful kernel.
- rca 13y ago
  Someone posted https://news.ycombinator.com/item?id=5771276 https://news.ycombinator.com/item?id=5771276 a few months ago. I'm not sure we could call that a kernel, but it's a first step.

by dkhenry 13y ago

pcwalton 13y ago

Three reasons. First, we don't control the kernel and we don't want to make assumptions about thread spawning being cheap on every OS. Second, it lets us implement work stealing, which is a proven method for dynamic parallelism. Third, it lets us do some operations such as RPC from task to task entirely in userspace with no trip through the scheduler or OS kernel.

jzwinck 13y ago
Good points. A counterpoint for #3 is that you could do kernel bypass RPC by installing a driver, but Rust developers probably don't want to write all those drivers, and Rust users wouldn't want to install them. Work (task) stealing is very compelling, and a little paradigm shift is no bad thing. If Rust or any new systems language stands a chance, it should aim high and not too close to the past.
- oconnor0 13y ago
  And then drivers would be required for each OS creating an additional porting burden.

srisa 13y ago

What if someone wants to write a kernel with Rust? This might be a very naive question taking into account my ignorance of language and kernel design.

marijn 13y ago
Look at https://github.com/pcwalton/zero.rs https://github.com/pcwalton/zero.rs . It's not very far yet, but it proves that it is viable to run Rust without a runtime.
- kibwen 13y ago
  I actually don't think we even need zero.rs anymore. Its purpose was to provide noop implementations for all the "lang items" that the compiler expects to find in the stdlib. However, post-0.7 the compiler no longer requires a lang item to be provided unless you actually use a feature that requires it. For an example, see the code at https://github.com/doublec/rust-from-c-example https://github.com/doublec/rust-from-c-example , which is fully runtimeless.
  - dbaupp 13y ago
    zero.rs (or something like it) is still required, because there's certain lang items that are required/useful (e.g. #[start], destructors, failure, vector bounds checks). (e.g. https://github.com/huonw/rust-malloc/blob/master/zero.rs https://github.com/huonw/rust-malloc/blob/master/zero.rs)
ldunn 13y ago
I've done some very preliminary (and bumbling) work with that at https://github.com/ldunn/kern/ https://github.com/ldunn/kern/ It's rudimentary, but it does compile and it does run, and I'm not aware of any particular obstacles to a more featureful kernel.
rca 13y ago
Someone posted https://news.ycombinator.com/item?id=5771276 https://news.ycombinator.com/item?id=5771276 a few months ago. I'm not sure we could call that a kernel, but it's a first step.