From: Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>
To: "glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>,
"frank.li@vivo.com" <frank.li@vivo.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"slava@dubeyko.com" <slava@dubeyko.com>
Subject: [RFC] Should we consider to re-write HFS/HFS+ in Rust?
Date: Tue, 27 May 2025 23:39:59 +0000 [thread overview]
Message-ID: <d5ea8adb198eb6b6d2f6accaf044b543631f7a72.camel@ibm.com> (raw)
Hi Adrian, Yangtao,
One idea crossed my mind recently. And this is about re-writing HFS/HFS+ in
Rust. It could be interesting direction but I am not sure how reasonable it
could be. From one point of view, HFS/HFS+ are not critical subsystems and we
can afford some experiments. From another point of view, we have enough issues
in the HFS/HFS+ code and, maybe, re-working HFS/HFS+ can make the code more
stable.
I don't think that it's a good idea to implement the complete re-writing of the
whole driver at once. However, we need a some unification and generalization of
HFS/HFS+ code patterns in the form of re-usable code by both drivers. This re-
usable code can be represented as by C code as by Rust code. And we can
introduce this generalized code in the form of C and Rust at the same time. So,
we can re-write HFS/HFS+ code gradually step by step. My point here that we
could have C code and Rust code for generalized functionality of HFS/HFS+ and
Kconfig would define which code will be compiled and used, finally.
How do you feel about this? And can we afford such implementation efforts?
Thanks,
Slava.
next reply other threads:[~2025-05-27 23:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 23:39 Viacheslav Dubeyko [this message]
2025-05-28 7:11 ` [RFC] Should we consider to re-write HFS/HFS+ in Rust? John Paul Adrian Glaubitz
2025-05-28 16:10 ` Viacheslav Dubeyko
2025-05-28 12:40 ` Yangtao Li
2025-05-28 16:16 ` Viacheslav Dubeyko
2025-06-19 19:33 ` Benno Lossin
2025-06-19 20:22 ` Miguel Ojeda
2025-06-19 21:48 ` Viacheslav Dubeyko
2025-06-19 22:00 ` Benno Lossin
2025-06-20 8:17 ` Miguel Ojeda
2025-06-20 18:10 ` Viacheslav Dubeyko
2025-06-20 19:27 ` Miguel Ojeda
2025-06-19 21:39 ` Viacheslav Dubeyko
2025-06-19 22:24 ` Benno Lossin
2025-06-20 17:46 ` Viacheslav Dubeyko
2025-06-20 18:11 ` Miguel Ojeda
2025-06-21 22:38 ` Viacheslav Dubeyko
2025-06-22 7:48 ` Benno Lossin
2025-06-23 10:25 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d5ea8adb198eb6b6d2f6accaf044b543631f7a72.camel@ibm.com \
--to=slava.dubeyko@ibm.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=slava@dubeyko.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).