The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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