Re: ostree oxidation: internal components written in Rust

Hi Colin,

On Wed, Dec 19, 2018 at 3:03 PM Colin Walters <walters verbum org> wrote:
On Tue, Dec 18, 2018, at 1:53 PM, Anton Gerasimov via ostree-list wrote:
We are using ostree in embedded Linux, built with minimal dependencies (in
terms of packages and cross-build tools) building it from Yocto.
Our interest is in having the ostree core available in C.

Same here. It is not impossible to build Rust code in Yocto, but it
increases maintenance burden and build time significantly.

Hmm; is there any discussion of this elsewhere - have any handy
links to e.g. mailing list archives?  Can you elaborate a bit
on the maintenance overhead?  Is it around dealing with sync?
On that topic I found

The discussions are spread out. Embedded is often "custom" so there is
not-so-much joint discussion on OSTree for embedded; there is QtOTA,
meta-ostree, meta-sota, and the Automotive Grade Linux group is doing
a lot with OSTree.

It's about a lot of things that embedded or distro builders care about:
-everything built from scratch (no pulling in binaries).
-stableness across all (Linux supported!) architectures
Rust for ARM is still tier 2:
Not to consider every other platform beyond x86. RISC-V is not even mentioned.
So we build everything ourselves; huge burden on OpenEmbedded/Yocto
project to consistently support languages as Go, Rust, etc.
-minimalism (think small initramfs and small-sized systems)
- cross-compile everything, no target side compilation or even
mutations (read-only!)

Having the client/target side in C is most preferable.
I do not think the server or build-side dependencies are still a big
hurdle, as Yocto is currently targetting x86 build systems only AFAIK.
However, this might shift.

For build time, is that building rustc for the host?  (including LLVM?) Or just general Rust
compilation times even on target?

At least for Yocto, there is NO compilation on the target. Everything
is cross-compiled. Personally I am more concerned with "target
footprint" rather than "build host footprint".

So: we may need to try to negotiate some sort of timeframe here.

Worst case, OSTree is good as it is at some point for our use case,
and users split of a fork that goes into bug-fix mode only. In time,
Rust support will catch up across platforms, and a step can be made to
re-join upstream OSTree.

Better case, but I am speaking from my personal standpoint, these
would be my humble wishes:
- Keep configurable.
- Keep Rust dependencies away from client side tools as long as possible.
- In all cases clearly stating what parts of the solution has what dependencies.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]