Re: The Case for Rust (in the base system)

On Sat, Jan 20, 2024 at 3:31 PM Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Sat, Jan 20, 2024 at 11:45 AM Aleksandr Fedorov <wigneddoom@yandex.ru> wrote:
>>
>> What about external dependencies?
>>
>> https://github.com/Axcient/freebsd-nfs-exporter/blob/master/Cargo.toml#L19
>> https://github.com/asomers/gstat-rs/blob/master/gstat/src/main.rs#L20
>>
>> Is there any plan for which crates we should take into the base system?
>>
>> We have had C++ in base for many years, but I don’t see any good libraries for CLI, logging, JSON, etc.
>>
>> https://doc.rust-lang.org/rustc/platform-support.html#tier-1-with-host-tools
>>
>> Where is the support for Freebsd as a primary platform? ARM, RISC-V, Power? Should we rewrite devd?
>>
>> I think we need to start by providing official repositories (e.g git.FreeBSD.org/rust.git or git.FreeBSD.org/go.git)
>> for different languages that include stable bindings to the system API:
>> - sysctl
>> - libgeom
>> - libifconfig
>> - netgraph
>> - jail
>> - etc.
>>
>> So that it’s not just some anonymous on crates.io that represents these bindings, but our community.
>> Officially, with support for a stable ABI for releases, security patches, etc.
>>
>> After this, it will be possible to think about which components to include in the base system.
>>
>> I would be glad to see a more modern language than C in the database, but I’m afraid that it will be like with C++,
>> that we will get a couple of daemons and utilities and that’s all.
>
>
> These are all good questions that need good answers, though necessarily to get started.
>
> But the other question that occured to me after my last posting was "What about build integration?"
> How much of the rust automation do we take in vs how much do we drive from a future bsd.rust.mk.
> I can sketch out bsd.rust.mk (to pick an arbitrary name, we'd likely need one for what we traditionally
> think of as libraries (which may or may not map 1:1 onto crates: we could have c callable libraries
> written in rust in the future, for example) and one for binaries.  Initially, though, if we go with the
> 'make rust tests possible' then we'd likely need the appropriate packages installed for whatever
> dependencies we'd have in the tests. This would give us a taste for what we'd need to do for
> base, I'd think. Once we had that notion, I can easily see there needing to be some sort of
> rust bindings for ATF/kyua as one of the first libraries / crates that would test that aspect of
> the build system. That all would be up to the people writing the tests in rust, I'd imagine.
>
> While I could jot out the basics of this integration (so one could just add the rust
> tools to a subdir or subdirs, include the bsd.rust.mk or whatever and then it would build
> if rust is enabled, and would emit a warning it was skipped because rust was disabled).
> We'd find out if this is workable or not and iterate from there. But that would also require
> active participation from the rust advocates to make it a reality: I can put together the
> build infrastructure for the disabled case, but likely can't on my own do the rust enabled
> case. I'd be happy to work with someone to do that, but I'm not going to be able to do
> that myself: my need for rust is slight, my knowledge of rust is weak, etc. Working with
> someone (or ideally several someones), though it could become reality. So please contact
> me if you'd like to work on this.

That sounds like a reasonable approach.  But what would be the first
tool or test suite to write in Rust?  The fusefs tests are now 16
kSLOC and I don't fancy rewriting them.  The tests that I DO want to
write are those that involve fsx-rs.  But those won't actually need
bsd.rust.mk, because they'll just be short sh scripts that invoke a
tool from ports.  I just need a ports committer to approve
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276005 .  ATM I
don't have a ready project to be imp's guinea pig.

-Alan