Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Windows-driver-samples
This repo contains driver samples prepared for use with Microsoft Visual Studio and the Windows Driver Kit (WDK). It contains both Universal Windows Driver and desktop-only driver samples.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I would be interested in what you think of something like BBQueue:
https://github.com/jamesmunns/bbqueue
Rust's String type is in the standard library [1], rather than in the language core where things like str live [2]. There's a lot of stuff in the standard library that assumes that it can allocate, and will panic on failure. The solution for now is simply to use Rust's `no_std` support [3] and not import the standard library into kernel code, since it's unsuitable for writing kernel code. In the longer term, Rust is investigating adding fallible variants for all of the standard library traits, so that kernel code could use the standard library with a compiler flag enabled that bans usage of any of the infallible standard library traits. There was a lot of discussion about this a few months ago in https://news.ycombinator.com/item?id=26812047.
[1] https://doc.rust-lang.org/std/string/struct.String.html
[2] https://doc.rust-lang.org/core/str/index.html
[3] https://docs.rust-embedded.org/book/intro/no-std.html
[4] https://github.com/rust-lang/rfcs/blob/master/text/2116-allo...
To clear something up here, while the Add trait is a language item, String is not. The String type is just a normal type implemented in liballoc[0]. As far as the language is concerned, there's nothing separating it from any other random type a user might write[1]. If you're in a no_std environment, String doesn't even exist unless you depend on liballoc.
The reason you can use String with the + and += operators is because it implements the Add and AddAssign traits[2], and it looks like the implementations are already feature gated for OOM handling so might not be implemented for String.
[0] https://github.com/rust-lang/rust/blob/master/library/alloc/...
[1] Note that the compiler knows about it to provide better diagnostics to the user, but this has no impact on the language itself.
[2] https://github.com/rust-lang/rust/blob/master/library/alloc/...
Well yes. But Linus is right on that one.
I wouldn't say Windows drivers were C++, more like "C with Classes" (and maybe a little bit C++)
Also, Windows drivers are usually much more convoluted than Linux drivers https://github.com/microsoft/Windows-driver-samples
C++, python, basic, or JS can work in kernel.
For example, Click modular router for Linux kerel is written in C++: https://github.com/pbuonado/click/blob/master/linuxmodule/mo...
Your examples will not compile without alloc. IMHO, kernel needs another kind of String type anyway, e.g. https://github.com/paulocsanz/arraystring .
I don't think so. Once a function is compiled, it basically becomes a black box with a type signature so unless sleeping in a function affects its signature, that information is erased. If you pass in some kind of a sleep token that has to be used to sleep, then yeah I think you could enforce it by only being able to get that token in a non-atomic context and making it leak proof.
The Cortex-M crate does something similar, but for proving that you are in an atomic context. Another function that expects a CriticalSection type is then assured that it's running without interrupts enabled.
https://github.com/rust-embedded/cortex-m/blob/master/src/in...