3 ms·
> The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol ex
by ogoffart 6y ago
> The ubiquitous kmalloc() function, for instance, is defined as __always_inline, meaning that it is inlined into all of its callers and no kmalloc() symbol exists in the kernel symbol table for Rust to link against. This problem can be easily worked around — one can define a kmalloc_for_rust() symbol containing an un-inlined version but performing these workarounds by hand would result in a large amount of manual work and duplicated code.
That's why there exists crates like https://docs.rs/cpp/ https://docs.rs/cpp/ which allow to embed C++ (and thus C) directly into the rust source code, simplifying the manual work and reducing the duplicated code.
- geofft 6y agoYup - that got a very brief mention in the article as "Google is working on automated C++ conversions"; there's also https://github.com/google/autocxx https://github.com/google/autocxx which builds on top of it. C++ is a richer language than C and has more information about ownership (e.g., if you return a std::string you know how ownership works; if you have two arguments that are a char * and a length it's much less clear), but additional annotations in the kernel's C headers to convey this level of information in a machine-parseable way would be awesome.
- ogoffart 6y agoThe cpp and cxx crates are two different crates with different goal. The cpp crate is about convenience, but require the use of unsafe within the rust code. The cxx crate do extra checks making the rust code safer but needs more boilerplate. In the case of C however, these type checking are not really possible, as you say.
- pjmlp 6y agoThat is one of the learnings Microsoft had with XP SP2, hence SAL macros everywhere on Windows APIs.