Re: [RFC PATCH 00/19] Rust abstractions for VFS

[Al Viro <viro@zeniv.linux.org.uk>]

On Wed, Jan 03, 2024 at 04:04:26PM -0300, Wedson Almeida Filho wrote:

> > Either stick to the object orientation we've already defined (ie
> > separate aops, iops, fops, ... with substantially similar arguments)
> > or propose changes to the ones we have in C.  Dealing only with toy
> > filesystems is leading you to bad architecture.
> 
> I'm trying to understand the argument here. Are saying that Rust
> cannot have different APIs with the same performance characteristics
> as C's, unless we also fix the C apis?

Different expressive power, not performance characteristics.

It's *NOT* about C vs Rust; we have an existing system of objects and
properties of such.  Independent from the language being used to work
with them.

If we have to keep a separate system for your language, feel free to fork
the kernel and do whatever you want with it.  Just don't expect anybody
else to play with your toy.

In case it's not entirely obvious - your arguments about not needing
something or other for the instances you have tried to work with so far
do not hold water.  At all.

The only acceptable way to use Rust in that space is to treat the existing
set of objects and operations as externally given; we *can* change those,
with good enough reasons, but "the instances in Rust-using filesystems 
don't need this and that" doesn't cut it.

Changes do happen in that area.  Often enough.  And the cost of figuring
out whether they break things shouldn't be doubled because Rust folks
want a universe of their own - the benefits of Rust are not worth that
kind of bother.