Re: A Demo of rust-in-base

On Sun, Aug 4, 2024 at 2:38 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> Warner Losh writes:
>
> > > > Because those two components need to be updated in lock-step with
> > > > potentially any git commit to the base system.  Not just official
> > > > releases, even minor ones.
> > >
> > > I'm not trying to be glib here: I really want to make sure I understand
> > > any fine nuances you are trying to communicate.
> > >
> > > Isn't that precisely what drm-kmod already deals with ?
> >
> > [...]
> >
> > The other is KBI and matching the kernel. The massive inlining in linuxkpi
> > make a stable KBI basically impossible [...]
>
> That was essentially my point:  We already have things in ports which
> are totally fragile relative to the kernel, so I want to make sure there
> is not som new/other/worse/different aspects in the two cases Alan
> brought up.

Yeah, the problem is pretty similar to what drm-kmod faces.  To
quantify the scale:
* Between 13.0-RELEASE and the latest stable/13 there were 61 changes
to tests/sys/fs/fusefs.
* 37 of those were paired with a kernel change, usually in the same commit.

If the fusefs test suite were external, that's 37 changes that would
need to be replicated in three places (freebsd-src, fusefs-tests, and
freebsd-ports).  Any user running the tests would need to build the
port about once per month, if they track stable/13.  Git archaeology
would be a lot harder.  And worst of all, MFCing changes from main to
stable branches would be very confusing.  Should the fusefs-tests
repository have its own stable branches?  Or would the stable branches
just not be tested?  Those are the reasons why I wrote the fusefs
tests in C++ instead of Rust, even though it's a lower productivity
language.

-Alan