On Wed, 3 Jan 2024 at 17:41, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Jan 03, 2024 at 02:14:34PM -0500, Kent Overstreet wrote: > > > We don't need to copy the C interface as is; we can use this as an > > opportunity to incrementally design a new API that will obviously take > > lessons from the C API (since it's wrapping it), but it doesn't have to > > do things the same and it doesn't have to do everything all at once. > > > > Anyways, like you alluded to the C side is a bit of a mess w.r.t. what's > > in a_ops vs. i_ops, and cleaning that up on the C side is a giant hassle > > because then you have to fix _everything_ that implements or consumes > > those interfaces at the same time. > > > > So instead, it would seem easier to me to do the cleaner version on the > > Rust side, and then once we know what that looks like, maybe we update > > the C version to match - or maybe we light it all on fire and continue > > with rewriting everything in Rust... *shrug* > > No. This "cleaner version on the Rust side" is nothing of that sort; > this "readdir doesn't need any state that might be different for different > file instances beyond the current position, because none of our examples > have needed that so far" is a good example of the garbage we really do > not need to deal with. What you're calling garbage is what Greg KH asked us to do, namely, not introduce anything for which there are no users. See a couple of quotes below. https://lore.kernel.org/rust-for-linux/2023081411-apache-tubeless-7bb3@gregkh/ The best feedback is "who will use these new interfaces?" Without that, it's really hard to review a patchset as it's difficult to see how the bindings will be used, right? https://lore.kernel.org/rust-for-linux/2023071049-gigabyte-timing-0673@gregkh/ And I'd recommend that we not take any more bindings without real users, as there seems to be just a collection of these and it's hard to actually review them to see how they are used... Cheers, -Wedson
