On Wed, Jan 03, 2024 at 07:53:58PM +0000, Al Viro wrote: > 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. The rust people have been getting conflicting advice, and your response is to tell them to fork the kernel and go away? > 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. The question was just about whether to add something now that isn't used on the Rust side yet, or wait until later when it is. I think this has gone a bit afield, and gotten a bit dramatic.
