From: "Theodore Ts'o" <tytso@mit.edu>
To: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Paul Walmsley <pjw@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1
Date: Thu, 2 Oct 2025 14:08:57 -0400 [thread overview]
Message-ID: <20251002180857.GA354523@mit.edu> (raw)
In-Reply-To: <3c9d9f92-aaf8-4d4d-a2d9-8d6a410edc30@codethink.co.uk>
On Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
>
> We first tackled big-endian support on ARM32 nearly 15 years ago, and
> drawing on that experience, we saw value in doing the same work on RISC-V as
> a way for newer engineers to gain hands-on experience contributing in the
> open.
Given the cost to the Linux kernel ecosystem as a whole, is giving
newer engineers "practice" really worth it? I'm not convinced it is.
> > RISC-V is enough of a mess with the millions of silly configuration
> > issues already. Don't make it even worse.
>
> This feels like the price you pay for making a flexible and free ecosystem
> to build cores.
Just because the RISC-V ecosystem wants to have a flexible ecosystem
doesn't mean that Linux kernel ecosystem is obliged to be just as
flexible, no?
- Ted
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: Ben Dooks <ben.dooks@codethink.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Paul Walmsley <pjw@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] RISC-V updates for v6.18-rc1
Date: Thu, 2 Oct 2025 14:08:57 -0400 [thread overview]
Message-ID: <20251002180857.GA354523@mit.edu> (raw)
In-Reply-To: <3c9d9f92-aaf8-4d4d-a2d9-8d6a410edc30@codethink.co.uk>
On Thu, Oct 02, 2025 at 01:48:47PM +0100, Ben Dooks wrote:
>
> We first tackled big-endian support on ARM32 nearly 15 years ago, and
> drawing on that experience, we saw value in doing the same work on RISC-V as
> a way for newer engineers to gain hands-on experience contributing in the
> open.
Given the cost to the Linux kernel ecosystem as a whole, is giving
newer engineers "practice" really worth it? I'm not convinced it is.
> > RISC-V is enough of a mess with the millions of silly configuration
> > issues already. Don't make it even worse.
>
> This feels like the price you pay for making a flexible and free ecosystem
> to build cores.
Just because the RISC-V ecosystem wants to have a flexible ecosystem
doesn't mean that Linux kernel ecosystem is obliged to be just as
flexible, no?
- Ted
next prev parent reply other threads:[~2025-10-02 18:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-29 8:00 [GIT PULL] RISC-V updates for v6.18-rc1 Paul Walmsley
2025-09-29 8:00 ` Paul Walmsley
2025-09-30 2:54 ` pr-tracker-bot
2025-09-30 2:54 ` pr-tracker-bot
2025-09-30 7:25 ` Ben Dooks
2025-09-30 7:25 ` Ben Dooks
2025-09-30 16:04 ` Linus Torvalds
2025-09-30 16:04 ` Linus Torvalds
2025-09-30 23:53 ` Linus Torvalds
2025-09-30 23:53 ` Linus Torvalds
2025-10-01 18:33 ` Eric Biggers
2025-10-01 18:33 ` Eric Biggers
2025-10-03 1:45 ` Yury Norov
2025-10-03 1:45 ` Yury Norov
2025-10-01 19:02 ` Conor Dooley
2025-10-01 19:02 ` Conor Dooley
2025-10-01 19:39 ` Linus Torvalds
2025-10-01 19:39 ` Linus Torvalds
2025-10-02 12:48 ` Ben Dooks
2025-10-02 12:48 ` Ben Dooks
2025-10-02 15:06 ` Olof Johansson
2025-10-02 15:06 ` Olof Johansson
2025-10-02 15:22 ` Ben Dooks
2025-10-02 15:22 ` Ben Dooks
2025-10-07 23:43 ` Maciej W. Rozycki
2025-10-07 23:43 ` Maciej W. Rozycki
2025-10-20 23:31 ` Paul Walmsley
2025-10-20 23:31 ` Paul Walmsley
2025-10-02 18:08 ` Theodore Ts'o [this message]
2025-10-02 18:08 ` Theodore Ts'o
2025-10-11 8:38 ` Yao Zi
2025-10-11 8:38 ` Yao Zi
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=20251002180857.GA354523@mit.edu \
--to=tytso@mit.edu \
--cc=ben.dooks@codethink.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=pjw@kernel.org \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.