linux-kernel - Re: [RFC PATCH 03/24] erofs: add Errno in Rust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <80cd0899-f14c-42f4-a0aa-3b8fa3717443@linux.alibaba.com>
Date: Thu, 26 Sep 2024 00:35:25 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Ariel Miculas <amiculas@...co.com>, Benno Lossin <benno.lossin@...ton.me>
Cc: Gary Guo <gary@...yguo.net>, Yiyang Wu <toolmanp@...p.cc>,
 rust-for-linux@...r.kernel.org,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 LKML <linux-kernel@...r.kernel.org>, Al Viro <viro@...iv.linux.org.uk>,
 linux-fsdevel@...r.kernel.org, linux-erofs@...ts.ozlabs.org,
 Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH 03/24] erofs: add Errno in Rust

Hi Ariel,

On 2024/9/25 23:48, Ariel Miculas wrote:

...

> I share the same opinions as Benno that we should try to use the
> existing filesystem abstractions, even if they are not yet upstream.
> Since erofs is a read-only filesystem and the Rust filesystem
> abstractions are also used by other two read-only filesystems (TarFS and
> PuzzleFS), it shouldn't be too difficult to adapt the erofs Rust code so
> that it also uses the existing filesystem abstractions. And if there is
> anything lacking, we can improve the existing generic APIs. This would
> also increase the chances of upstreaming them.

I've expressed my ideas about "TarFS" [1] and PuzzleFS already: since
I'm one of the EROFS authors, I should be responsible for this
long-term project as my own promise to the Linux community and makes
it serve for more Linux users (it has not been interrupted since 2017,
even I sacrificed almost all my leisure time because the EROFS project
isn't all my paid job, I need to maintain our internal kernel storage
stack too).

[1] https://lore.kernel.org/r/3a6314fc-7956-47f3-8727-9dc026f3f50e@linux.alibaba.com

Basically there should be some good reasons to upstream a new stuff to
Linux kernel, I believe it has no exception on the Rust side even it's
somewhat premature: please help compare to the prior arts in details.

And there are all thoughts for reference [2][3][4][5]:
[2] https://github.com/project-machine/puzzlefs/issues/114#issuecomment-2369872133
[3] https://github.com/opencontainers/image-spec/issues/1190#issuecomment-2138572683
[4] https://lore.kernel.org/linux-fsdevel/b9358e7c-8615-1b12-e35d-aae59bf6a467@linux.alibaba.com/
[5] https://lore.kernel.org/linux-fsdevel/20230609-nachrangig-handwagen-375405d3b9f1@brauner/

Here still, I do really want to collaborate with you on your
reasonable use cases.  But if you really want to do your upstream
attempt without even any comparsion, please go ahead because I
believe I can only express my own opinion, but I really don't
decide if your work is acceptable for the kernel.

> 
> I'm happy to help you if you decide to go down this route.

Again, the current VFS abstraction is totally incomplete and broken
[6].

I believe it should be driven by a full-featured read-write fs [7]
(even like a simple minix fs in pre-Linux 1.0 era) and EROFS will
use Rust in "fs/erofs" as the experiment, but I will definitely
polish the Rust version until it looks good before upstreaming.

I really don't want to be a repeater again.

[6] https://lwn.net/SubscriberLink/991062/9de8e9a466a3faf5
[7] https://lore.kernel.org/linux-fsdevel/ZZ3GeehAw%2F78gZJk@dread.disaster.area

Thanks,
Gao Xiang

> 
> Cheers,
> Ariel