> А что-нибудь новое на расте пишут или только переписывают уже работающее?

Zed зарелизили намедни. Но пока только для iOS.

> Раст умеет в ядре экспортировать свой API или только через сишные обёртки и соответственно через обмазывание unsafe?

#[repr(C)] функции имеют C'шный ABI, их можно вызывать из C кода непосредственно.

Но, скорее всего, эти #[repr(C)] функции будут обёртками, чьей задачей будет решить в чём доверять C'шному коду, а в чём нет, посредством приведения типов.

Например, если в функцию передаются указатели, то они будут raw указателями, и rustc не может ничего гарантировать относительно них. Тебе придётся принять решение за rustc и сказать, что валидности этого указателя можно верить, и при помощи unsafe преобразовать его к &-указателю.

Плюс могут быть другие нюансы типа impedance mismatch. Например, rust'овые строки гарантированно валидный utf8, все строковые функции полагаются на это, и могут сегфолтнуть на невалидном utf8. То есть если ты хочешь работать со строкой полученной от C-кода как с &str, тебе придётся проверять на валидность utf8 или просто поверить в валидность и принять без проверки. Ещё с длиной придётся выкручиваться, считать её перед кастом. В ядре, я подозреваю, они используют не &str, а &CStr или что-нибудь своё доморощенное в этом стиле. Но даже в случае доморощенного типа-обёртки придётся принимать решение -- считать ли длину строки перед приведением типа, или работать со строкой в C'шном стиле, не зная её размера.

В общем, на стыке C и Rust придётся какие-то танцы с бубном выполнять, и там неизбежно полезут unsafe'ы, потому что rustc не может ничего предполагать о поведении C'шного кода. И вероятно придётся создавать обёртки, которые будут заниматься исключительно этим -- приведением типов, где-то выполняя дополнительные рантайм проверки, где-то просто волевым решением заявляя расту "этот указатель считать валидным".