From: Jens Axboe <axboe@kernel.dk>
To: Jason Xing <kerneljasonxing@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
corbet@lwn.net, linux-doc@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
linux@treblig.org, viro@zeniv.linux.org.uk
Subject: Re: [PATCH] relay: Remove unused relay_late_setup_files
Date: Tue, 13 May 2025 07:26:47 -0600 [thread overview]
Message-ID: <4ee5429c-7bb6-4c92-ad28-8e0d8454d4b0@kernel.dk> (raw)
In-Reply-To: <CAL+tcoC9ioDpM93nHpoUS9icqG+pZvZU6mCEz1HbCrENrPeKwQ@mail.gmail.com>
On 5/12/25 8:17 PM, Jason Xing wrote:
> On Tue, May 13, 2025 at 9:49?AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 5/12/25 6:49 PM, Jason Xing wrote:
>>> On Mon, May 12, 2025 at 10:55?PM Christoph Hellwig <hch@infradead.org> wrote:
>>>>
>>>> On Mon, May 12, 2025 at 09:14:56AM +0300, Andy Shevchenko wrote:
>>>>> Also note, we usually do not care about the out-of-tree users. The main Q here
>>>>> why are they out-of-tree for so long time?
>>>>
>>>> We do not care. If some of this ever gets submitted it can add the
>>>> needed helpers back.
>>>>
>>>> This entire discussion is silly.
>>>>
>>>
>>> I'm surprised how you described it....
>>>
>>> Now relay works like a filesystem which helps out-of-tree users
>>> transfer a large amount of data efficiently. it's totally not like
>>> other pure dead code. I meant what the trouble of just leaving it
>>> untouched in the kernel could be?
>>>
>>> Let me put in a simpler way, two options, 1) just clean up, 2) keep it
>>> and help so-called 'out-of-tree' users even if you don't care. I don't
>>> figure out what the difficulty of keeping it is :S
>>
>> I think Christoph's email was quite clear, and I also said _exactly_ the
>> same thing in an email two days ago: we never EVER keep code in
>> kernel that isn't used by in-kernel code. Period. It's not a debate,
>> this is the law, if you will. It's a core principle because it allows
>> the kernel to be maintainable, rather than need to care about out of
>> tree code when changes are made. Similarly, we don't have a kernel API,
>> not even at the source level.
>>
>> This is one of the core tenets of the Linux kernel, and all in-tree code
>> must follow those. If you have aspirations of maintaining the relay code
>> going forward, you need to fully understand that. Either the dead code
>> goes, or the out-of-tree code that uses it must be merged. There's no
>> in-between.
>
> Thanks for clarifying this to me.
>
> At the moment, it seems the relay is still alive because of blktrace.
> It looks like two options for me who wish to enhance the relay feature
> in the long run:
> 1) merge the networking trace feature that relies on relay.
> 2) turn it into a file system
>
> Seems option #2 is a more generic way to go?
Seems to me like option 1 would be the way to go. There's no point
making something generic just for the sake of it, and particularly not
if the goal is just to enable some out-of-tree use cases. That's not the
kernel way...
> From the bottom of my heart, I really don't want to lose any 'unused'
> parts in the relay because there are still more unused functions...
I don't understand that part - the code is managed by git, it'll be in
history forever. There's no losing, it's very much still there. If you
or someone else needs to bring it back, it's _trivial_ to do so.
Being hesitant to remove code for sentimental reasons is a mistake. The
more code removed, the less to maintain. Win win.
--
Jens Axboe
next prev parent reply other threads:[~2025-05-13 13:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 1:12 [PATCH] relay: Remove unused relay_late_setup_files Jason Xing
2025-05-12 1:30 ` Dr. David Alan Gilbert
2025-05-12 2:22 ` Jason Xing
2025-05-12 11:50 ` Dr. David Alan Gilbert
2025-05-12 12:04 ` Jason Xing
2025-05-12 6:14 ` Andy Shevchenko
2025-05-12 6:17 ` Andy Shevchenko
2025-05-12 6:55 ` Jason Xing
2025-05-12 7:25 ` Andy Shevchenko
2025-05-12 6:53 ` Jason Xing
2025-05-12 7:21 ` Andy Shevchenko
2025-05-12 7:34 ` Jason Xing
2025-05-12 13:27 ` Jens Axboe
2025-05-12 14:55 ` Christoph Hellwig
2025-05-13 0:49 ` Jason Xing
2025-05-13 1:49 ` Jens Axboe
2025-05-13 2:17 ` Jason Xing
2025-05-13 13:26 ` Jens Axboe [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-04-18 23:49 linux
2025-04-20 21:07 ` Andrew Morton
2025-04-23 20:12 ` Jens Axboe
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=4ee5429c-7bb6-4c92-ad28-8e0d8454d4b0@kernel.dk \
--to=axboe@kernel.dk \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=kerneljasonxing@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@treblig.org \
--cc=viro@zeniv.linux.org.uk \
/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