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: <CAL+tcoC9ioDpM93nHpoUS9icqG+pZvZU6mCEz1HbCrENrPeKwQ@mail.gmail.com>
Date: Tue, 13 May 2025 10:17:31 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Jens Axboe <axboe@...nel.dk>
Cc: Christoph Hellwig <hch@...radead.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, corbet@....net, linux-doc@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>, linux@...blig.org, viro@...iv.linux.org.uk
Subject: Re: [PATCH] relay: Remove unused relay_late_setup_files

On Tue, May 13, 2025 at 9:49 AM Jens Axboe <axboe@...nel.dk> wrote:
>
> On 5/12/25 6:49 PM, Jason Xing wrote:
> > On Mon, May 12, 2025 at 10:55?PM Christoph Hellwig <hch@...radead.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?

>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...

Thanks,
Jason

>
> --
> Jens Axboe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ