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.
