[PATCH] relay: Remove unused relay_late_setup_files

[PATCH] relay: Remove unused relay_late_setup_files

[linux]

From: "Dr. David Alan Gilbert" <linux@treblig.org>

The last use of relay_late_setup_files() was removed in 2018
by commit 2b47733045aa ("drm/i915/guc: Merge log relay file and channel
creation")

Remove it and the helper it used.

relay_late_setup_files() was used for eventually registering
'buffer only' channels.  With it gone, delete the docs that
explain how to do that.   Which suggests it should be possible
to lose the 'has_base_filename' flags.

(Are there any other uses??)

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
---
 Documentation/filesystems/relay.rst |  10 ---
 include/linux/relay.h               |   3 -
 kernel/relay.c                      | 111 +---------------------------
 3 files changed, 1 insertion(+), 123 deletions(-)

diff --git a/Documentation/filesystems/relay.rst b/Documentation/filesystems/relay.rst
index 04ad083cfe62..292ba8492aeb 100644
--- a/Documentation/filesystems/relay.rst
+++ b/Documentation/filesystems/relay.rst
@@ -301,16 +301,6 @@ user-defined data with a channel, and is immediately available
 (including in create_buf_file()) via chan->private_data or
 buf->chan->private_data.
 
-Buffer-only channels
---------------------
-
-These channels have no files associated and can be created with
-relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
-as when doing early tracing in the kernel, before the VFS is up. In these
-cases, one may open a buffer-only channel and then call
-relay_late_setup_files() when the kernel is ready to handle files,
-to expose the buffered data to the userspace.
-
 Channel 'modes'
 ---------------
 
diff --git a/include/linux/relay.h b/include/linux/relay.h
index 72b876dd5cb8..b3224111d074 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -159,9 +159,6 @@ struct rchan *relay_open(const char *base_filename,
 			 size_t n_subbufs,
 			 const struct rchan_callbacks *cb,
 			 void *private_data);
-extern int relay_late_setup_files(struct rchan *chan,
-				  const char *base_filename,
-				  struct dentry *parent);
 extern void relay_close(struct rchan *chan);
 extern void relay_flush(struct rchan *chan);
 extern void relay_subbufs_consumed(struct rchan *chan,
diff --git a/kernel/relay.c b/kernel/relay.c
index 5ac7e711e4b6..c0c93a04d4ce 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -452,7 +452,7 @@ int relay_prepare_cpu(unsigned int cpu)
 
 /**
  *	relay_open - create a new relay channel
- *	@base_filename: base name of files to create, %NULL for buffering only
+ *	@base_filename: base name of files to create
  *	@parent: dentry of parent directory, %NULL for root directory or buffer
  *	@subbuf_size: size of sub-buffers
  *	@n_subbufs: number of sub-buffers
@@ -465,10 +465,6 @@ int relay_prepare_cpu(unsigned int cpu)
  *	attributes specified.  The created channel buffer files
  *	will be named base_filename0...base_filenameN-1.  File
  *	permissions will be %S_IRUSR.
- *
- *	If opening a buffer (@parent = NULL) that you later wish to register
- *	in a filesystem, call relay_late_setup_files() once the @parent dentry
- *	is available.
  */
 struct rchan *relay_open(const char *base_filename,
 			 struct dentry *parent,
@@ -540,111 +536,6 @@ struct rchan_percpu_buf_dispatcher {
 	struct dentry *dentry;
 };
 
-/* Called in atomic context. */
-static void __relay_set_buf_dentry(void *info)
-{
-	struct rchan_percpu_buf_dispatcher *p = info;
-
-	relay_set_buf_dentry(p->buf, p->dentry);
-}
-
-/**
- *	relay_late_setup_files - triggers file creation
- *	@chan: channel to operate on
- *	@base_filename: base name of files to create
- *	@parent: dentry of parent directory, %NULL for root directory
- *
- *	Returns 0 if successful, non-zero otherwise.
- *
- *	Use to setup files for a previously buffer-only channel created
- *	by relay_open() with a NULL parent dentry.
- *
- *	For example, this is useful for perfomring early tracing in kernel,
- *	before VFS is up and then exposing the early results once the dentry
- *	is available.
- */
-int relay_late_setup_files(struct rchan *chan,
-			   const char *base_filename,
-			   struct dentry *parent)
-{
-	int err = 0;
-	unsigned int i, curr_cpu;
-	unsigned long flags;
-	struct dentry *dentry;
-	struct rchan_buf *buf;
-	struct rchan_percpu_buf_dispatcher disp;
-
-	if (!chan || !base_filename)
-		return -EINVAL;
-
-	strscpy(chan->base_filename, base_filename, NAME_MAX);
-
-	mutex_lock(&relay_channels_mutex);
-	/* Is chan already set up? */
-	if (unlikely(chan->has_base_filename)) {
-		mutex_unlock(&relay_channels_mutex);
-		return -EEXIST;
-	}
-	chan->has_base_filename = 1;
-	chan->parent = parent;
-
-	if (chan->is_global) {
-		err = -EINVAL;
-		buf = *per_cpu_ptr(chan->buf, 0);
-		if (!WARN_ON_ONCE(!buf)) {
-			dentry = relay_create_buf_file(chan, buf, 0);
-			if (dentry && !WARN_ON_ONCE(!chan->is_global)) {
-				relay_set_buf_dentry(buf, dentry);
-				err = 0;
-			}
-		}
-		mutex_unlock(&relay_channels_mutex);
-		return err;
-	}
-
-	curr_cpu = get_cpu();
-	/*
-	 * The CPU hotplug notifier ran before us and created buffers with
-	 * no files associated. So it's safe to call relay_setup_buf_file()
-	 * on all currently online CPUs.
-	 */
-	for_each_online_cpu(i) {
-		buf = *per_cpu_ptr(chan->buf, i);
-		if (unlikely(!buf)) {
-			WARN_ONCE(1, KERN_ERR "CPU has no buffer!\n");
-			err = -EINVAL;
-			break;
-		}
-
-		dentry = relay_create_buf_file(chan, buf, i);
-		if (unlikely(!dentry)) {
-			err = -EINVAL;
-			break;
-		}
-
-		if (curr_cpu == i) {
-			local_irq_save(flags);
-			relay_set_buf_dentry(buf, dentry);
-			local_irq_restore(flags);
-		} else {
-			disp.buf = buf;
-			disp.dentry = dentry;
-			smp_mb();
-			/* relay_channels_mutex must be held, so wait. */
-			err = smp_call_function_single(i,
-						       __relay_set_buf_dentry,
-						       &disp, 1);
-		}
-		if (unlikely(err))
-			break;
-	}
-	put_cpu();
-	mutex_unlock(&relay_channels_mutex);
-
-	return err;
-}
-EXPORT_SYMBOL_GPL(relay_late_setup_files);
-
 /**
  *	relay_switch_subbuf - switch to a new sub-buffer
  *	@buf: channel buffer
-- 
2.49.0

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Andrew Morton]

On Sat, 19 Apr 2025 00:49:32 +0100 linux@treblig.org wrote:

> From: "Dr. David Alan Gilbert" <linux@treblig.org>
> 
> The last use of relay_late_setup_files() was removed in 2018
> by commit 2b47733045aa ("drm/i915/guc: Merge log relay file and channel
> creation")
> 
> Remove it and the helper it used.
> 
> relay_late_setup_files() was used for eventually registering
> 'buffer only' channels.  With it gone, delete the docs that
> explain how to do that.   Which suggests it should be possible
> to lose the 'has_base_filename' flags.
> 
> (Are there any other uses??)
> 

For some reason get_maintainer points at Al and Andy for relay.c but my
mental rolodex thinks "Axboe".

Jens, does this look OK?

> ---
>  Documentation/filesystems/relay.rst |  10 ---
>  include/linux/relay.h               |   3 -
>  kernel/relay.c                      | 111 +---------------------------
>  3 files changed, 1 insertion(+), 123 deletions(-)
> 
> diff --git a/Documentation/filesystems/relay.rst b/Documentation/filesystems/relay.rst
> index 04ad083cfe62..292ba8492aeb 100644
> --- a/Documentation/filesystems/relay.rst
> +++ b/Documentation/filesystems/relay.rst
> @@ -301,16 +301,6 @@ user-defined data with a channel, and is immediately available
>  (including in create_buf_file()) via chan->private_data or
>  buf->chan->private_data.
>  
> -Buffer-only channels
> ---------------------
> -
> -These channels have no files associated and can be created with
> -relay_open(NULL, NULL, ...). Such channels are useful in scenarios such
> -as when doing early tracing in the kernel, before the VFS is up. In these
> -cases, one may open a buffer-only channel and then call
> -relay_late_setup_files() when the kernel is ready to handle files,
> -to expose the buffered data to the userspace.
> -
>  Channel 'modes'
>  ---------------
>  
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index 72b876dd5cb8..b3224111d074 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -159,9 +159,6 @@ struct rchan *relay_open(const char *base_filename,
>  			 size_t n_subbufs,
>  			 const struct rchan_callbacks *cb,
>  			 void *private_data);
> -extern int relay_late_setup_files(struct rchan *chan,
> -				  const char *base_filename,
> -				  struct dentry *parent);
>  extern void relay_close(struct rchan *chan);
>  extern void relay_flush(struct rchan *chan);
>  extern void relay_subbufs_consumed(struct rchan *chan,
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 5ac7e711e4b6..c0c93a04d4ce 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -452,7 +452,7 @@ int relay_prepare_cpu(unsigned int cpu)
>  
>  /**
>   *	relay_open - create a new relay channel
> - *	@base_filename: base name of files to create, %NULL for buffering only
> + *	@base_filename: base name of files to create
>   *	@parent: dentry of parent directory, %NULL for root directory or buffer
>   *	@subbuf_size: size of sub-buffers
>   *	@n_subbufs: number of sub-buffers
> @@ -465,10 +465,6 @@ int relay_prepare_cpu(unsigned int cpu)
>   *	attributes specified.  The created channel buffer files
>   *	will be named base_filename0...base_filenameN-1.  File
>   *	permissions will be %S_IRUSR.
> - *
> - *	If opening a buffer (@parent = NULL) that you later wish to register
> - *	in a filesystem, call relay_late_setup_files() once the @parent dentry
> - *	is available.
>   */
>  struct rchan *relay_open(const char *base_filename,
>  			 struct dentry *parent,
> @@ -540,111 +536,6 @@ struct rchan_percpu_buf_dispatcher {
>  	struct dentry *dentry;
>  };
>  
> -/* Called in atomic context. */
> -static void __relay_set_buf_dentry(void *info)
> -{
> -	struct rchan_percpu_buf_dispatcher *p = info;
> -
> -	relay_set_buf_dentry(p->buf, p->dentry);
> -}
> -
> -/**
> - *	relay_late_setup_files - triggers file creation
> - *	@chan: channel to operate on
> - *	@base_filename: base name of files to create
> - *	@parent: dentry of parent directory, %NULL for root directory
> - *
> - *	Returns 0 if successful, non-zero otherwise.
> - *
> - *	Use to setup files for a previously buffer-only channel created
> - *	by relay_open() with a NULL parent dentry.
> - *
> - *	For example, this is useful for perfomring early tracing in kernel,
> - *	before VFS is up and then exposing the early results once the dentry
> - *	is available.
> - */
> -int relay_late_setup_files(struct rchan *chan,
> -			   const char *base_filename,
> -			   struct dentry *parent)
> -{
> -	int err = 0;
> -	unsigned int i, curr_cpu;
> -	unsigned long flags;
> -	struct dentry *dentry;
> -	struct rchan_buf *buf;
> -	struct rchan_percpu_buf_dispatcher disp;
> -
> -	if (!chan || !base_filename)
> -		return -EINVAL;
> -
> -	strscpy(chan->base_filename, base_filename, NAME_MAX);
> -
> -	mutex_lock(&relay_channels_mutex);
> -	/* Is chan already set up? */
> -	if (unlikely(chan->has_base_filename)) {
> -		mutex_unlock(&relay_channels_mutex);
> -		return -EEXIST;
> -	}
> -	chan->has_base_filename = 1;
> -	chan->parent = parent;
> -
> -	if (chan->is_global) {
> -		err = -EINVAL;
> -		buf = *per_cpu_ptr(chan->buf, 0);
> -		if (!WARN_ON_ONCE(!buf)) {
> -			dentry = relay_create_buf_file(chan, buf, 0);
> -			if (dentry && !WARN_ON_ONCE(!chan->is_global)) {
> -				relay_set_buf_dentry(buf, dentry);
> -				err = 0;
> -			}
> -		}
> -		mutex_unlock(&relay_channels_mutex);
> -		return err;
> -	}
> -
> -	curr_cpu = get_cpu();
> -	/*
> -	 * The CPU hotplug notifier ran before us and created buffers with
> -	 * no files associated. So it's safe to call relay_setup_buf_file()
> -	 * on all currently online CPUs.
> -	 */
> -	for_each_online_cpu(i) {
> -		buf = *per_cpu_ptr(chan->buf, i);
> -		if (unlikely(!buf)) {
> -			WARN_ONCE(1, KERN_ERR "CPU has no buffer!\n");
> -			err = -EINVAL;
> -			break;
> -		}
> -
> -		dentry = relay_create_buf_file(chan, buf, i);
> -		if (unlikely(!dentry)) {
> -			err = -EINVAL;
> -			break;
> -		}
> -
> -		if (curr_cpu == i) {
> -			local_irq_save(flags);
> -			relay_set_buf_dentry(buf, dentry);
> -			local_irq_restore(flags);
> -		} else {
> -			disp.buf = buf;
> -			disp.dentry = dentry;
> -			smp_mb();
> -			/* relay_channels_mutex must be held, so wait. */
> -			err = smp_call_function_single(i,
> -						       __relay_set_buf_dentry,
> -						       &disp, 1);
> -		}
> -		if (unlikely(err))
> -			break;
> -	}
> -	put_cpu();
> -	mutex_unlock(&relay_channels_mutex);
> -
> -	return err;
> -}
> -EXPORT_SYMBOL_GPL(relay_late_setup_files);
> -
>  /**
>   *	relay_switch_subbuf - switch to a new sub-buffer
>   *	@buf: channel buffer
> -- 
> 2.49.0

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jens Axboe]

On 4/20/25 3:07 PM, Andrew Morton wrote:
> On Sat, 19 Apr 2025 00:49:32 +0100 linux@treblig.org wrote:
> 
>> From: "Dr. David Alan Gilbert" <linux@treblig.org>
>>
>> The last use of relay_late_setup_files() was removed in 2018
>> by commit 2b47733045aa ("drm/i915/guc: Merge log relay file and channel
>> creation")
>>
>> Remove it and the helper it used.
>>
>> relay_late_setup_files() was used for eventually registering
>> 'buffer only' channels.  With it gone, delete the docs that
>> explain how to do that.   Which suggests it should be possible
>> to lose the 'has_base_filename' flags.
>>
>> (Are there any other uses??)
>>
> 
> For some reason get_maintainer points at Al and Andy for relay.c but my
> mental rolodex thinks "Axboe".

Heh, probably because I did dabble in it 20 YEARS AGO as we used it for
the original blktrace! I'm not saying we're both old, but...

> Jens, does this look OK?

Looks fine to me.

Reviewed-by: Jens Axboe <axboe@kernel.dk>

-- 
Jens Axboe

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

Hi All,

I noticed this patch "relay: Remove unused relay_late_setup_files"
appears in the mm branch already[1], which I totally missed. Sorry for
joining the party late.

I have a different opinion on this. For me, I'm very cautious about
what those so-called legacy interfaces are and how they can work in
different cases and what the use case might be... There are still a
small number of out-of-tree users like me heavily relying on relayfs
mechanism. So my humble opinion is that if you want to remove
so-called dead code, probably clearly state why it cannot be used
anymore in the future.

Dr. David, I appreciate your patch, but please do not simply do the
random cleanup work __here__. If you take a deep look at the relayfs,
you may find there are other interfaces/functions no one uses in the
kernel tree.

I'm now checking this kind of patch in relayfs one by one to avoid
such a thing happening. I'm trying to maintain it as much as possible
since we internally use it in the networking area to output useful
information in the hot paths, a little bit like blktrace. BTW, relayfs
is really a wonderful one that helps kernel modules communicate with
userspace very efficiently. I'm trying to revive it if I can.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997

Thanks,
Jason

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Dr. David Alan Gilbert]

* Jason Xing (kerneljasonxing@gmail.com) wrote:
> Hi All,

Hi Jason,

> I noticed this patch "relay: Remove unused relay_late_setup_files"
> appears in the mm branch already[1], which I totally missed. Sorry for
> joining the party late.
> 
> I have a different opinion on this. For me, I'm very cautious about
> what those so-called legacy interfaces are and how they can work in
> different cases and what the use case might be... There are still a
> small number of out-of-tree users like me heavily relying on relayfs
> mechanism. So my humble opinion is that if you want to remove
> so-called dead code, probably clearly state why it cannot be used
> anymore in the future.

We've got lots of deadcode, why it's dead varies a lot; for example
people forgetting to clean it up after other patches etc - so this
_could_ be used but hasn't been for well over 7 years.

> Dr. David, I appreciate your patch, but please do not simply do the
> random cleanup work __here__. If you take a deep look at the relayfs,
> you may find there are other interfaces/functions no one uses in the
> kernel tree.

Actually, that was the only interface in relay that I found unused.

> I'm now checking this kind of patch in relayfs one by one to avoid
> such a thing happening. I'm trying to maintain it as much as possible
> since we internally use it in the networking area to output useful
> information in the hot paths, a little bit like blktrace. BTW, relayfs
> is really a wonderful one that helps kernel modules communicate with
> userspace very efficiently. I'm trying to revive it if I can.

If you've got a use for that function, then I'm more than happy to suggest
just dropping my patch.

However, it is a fairly chunky function that is built into distro
kernels - so I think it should have a little thought put to it.

As I say, if you are using it, it's fine by me just to drop this patch.

Dave

> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
> 
> Thanks,
> Jason
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

On Mon, May 12, 2025 at 9:30 AM Dr. David Alan Gilbert
<linux@treblig.org> wrote:
>
> * Jason Xing (kerneljasonxing@gmail.com) wrote:
> > Hi All,
>
> Hi Jason,
>
> > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > appears in the mm branch already[1], which I totally missed. Sorry for
> > joining the party late.
> >
> > I have a different opinion on this. For me, I'm very cautious about
> > what those so-called legacy interfaces are and how they can work in
> > different cases and what the use case might be... There are still a
> > small number of out-of-tree users like me heavily relying on relayfs
> > mechanism. So my humble opinion is that if you want to remove
> > so-called dead code, probably clearly state why it cannot be used
> > anymore in the future.
>
> We've got lots of deadcode, why it's dead varies a lot; for example
> people forgetting to clean it up after other patches etc - so this
> _could_ be used but hasn't been for well over 7 years.
>
> > Dr. David, I appreciate your patch, but please do not simply do the
> > random cleanup work __here__. If you take a deep look at the relayfs,
> > you may find there are other interfaces/functions no one uses in the
> > kernel tree.
>
> Actually, that was the only interface in relay that I found unused.

Not really. More than this single one, say, __relay_write() and
subbuf_start_reserve()...

>
> > I'm now checking this kind of patch in relayfs one by one to avoid
> > such a thing happening. I'm trying to maintain it as much as possible
> > since we internally use it in the networking area to output useful
> > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > is really a wonderful one that helps kernel modules communicate with
> > userspace very efficiently. I'm trying to revive it if I can.
>
> If you've got a use for that function, then I'm more than happy to suggest
> just dropping my patch.
>
> However, it is a fairly chunky function that is built into distro
> kernels - so I think it should have a little thought put to it.
>
> As I say, if you are using it, it's fine by me just to drop this patch.

For now, I'm not using it but still considering what the use case
might be in the future. As I mentioned earlier, I'm trying to make
relayfs more robust with more realistic functions.

IMHO, it's not really a dead code to me unless you can clarify why
it's obsolete instead of claiming "no one is using it". If you insist
on the point, then most of relayfs would be removed, which is
apparently not what I'm wishing for.

Probably it will be finally removed, but not at the moment. Evidence
is still not clear to me :S

For sure, the last call would be made by Andrew and Jens. Please help
review this patch one more time. Thanks!

Thanks,
Jason

>
> Dave
>
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
> >
> > Thanks,
> > Jason
> --
>  -----Open up your eyes, open up your mind, open up your code -------
> / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> \        dave @ treblig.org |                               | In Hex /
>  \ _________________________|_____ http://www.treblig.org   |_______/

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Andy Shevchenko]

On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> Hi All,
> 
> I noticed this patch "relay: Remove unused relay_late_setup_files"
> appears in the mm branch already[1], which I totally missed. Sorry for
> joining the party late.
> 
> I have a different opinion on this. For me, I'm very cautious about
> what those so-called legacy interfaces are and how they can work in
> different cases and what the use case might be... There are still a
> small number of out-of-tree users like me heavily relying on relayfs
> mechanism. So my humble opinion is that if you want to remove
> so-called dead code, probably clearly state why it cannot be used
> anymore in the future.
> 
> Dr. David, I appreciate your patch, but please do not simply do the
> random cleanup work __here__. If you take a deep look at the relayfs,
> you may find there are other interfaces/functions no one uses in the
> kernel tree.
> 
> I'm now checking this kind of patch in relayfs one by one to avoid
> such a thing happening. I'm trying to maintain it as much as possible
> since we internally use it in the networking area to output useful
> information in the hot paths, a little bit like blktrace. BTW, relayfs
> is really a wonderful one that helps kernel modules communicate with
> userspace very efficiently. I'm trying to revive it if I can.

Jason, with all of the respect, if you are interested in keeping things going
on, please add yourself to the MAINTAINERS. It will makes the users of the
legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
and you happy.

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?

> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Andy Shevchenko]

On Mon, May 12, 2025 at 09:14:56AM +0300, Andy Shevchenko wrote:
> On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > Hi All,
> > 
> > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > appears in the mm branch already[1], which I totally missed. Sorry for
> > joining the party late.
> > 
> > I have a different opinion on this. For me, I'm very cautious about
> > what those so-called legacy interfaces are and how they can work in
> > different cases and what the use case might be... There are still a
> > small number of out-of-tree users like me heavily relying on relayfs
> > mechanism. So my humble opinion is that if you want to remove
> > so-called dead code, probably clearly state why it cannot be used
> > anymore in the future.
> > 
> > Dr. David, I appreciate your patch, but please do not simply do the
> > random cleanup work __here__. If you take a deep look at the relayfs,
> > you may find there are other interfaces/functions no one uses in the
> > kernel tree.
> > 
> > I'm now checking this kind of patch in relayfs one by one to avoid
> > such a thing happening. I'm trying to maintain it as much as possible
> > since we internally use it in the networking area to output useful
> > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > is really a wonderful one that helps kernel modules communicate with
> > userspace very efficiently. I'm trying to revive it if I can.
> 
> Jason, with all of the respect, if you are interested in keeping things going
> on, please add yourself to the MAINTAINERS. It will makes the users of the
> legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> and you happy.
> 
> 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?
> 
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997

With the above being said, I am +1 for the patch to stay. Feel free to send
a revert with a good justification of why it should stay. Note, out-of-tree
is not enough argument.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

On Mon, May 12, 2025 at 2:15 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > Hi All,
> >
> > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > appears in the mm branch already[1], which I totally missed. Sorry for
> > joining the party late.
> >
> > I have a different opinion on this. For me, I'm very cautious about
> > what those so-called legacy interfaces are and how they can work in
> > different cases and what the use case might be... There are still a
> > small number of out-of-tree users like me heavily relying on relayfs
> > mechanism. So my humble opinion is that if you want to remove
> > so-called dead code, probably clearly state why it cannot be used
> > anymore in the future.
> >
> > Dr. David, I appreciate your patch, but please do not simply do the
> > random cleanup work __here__. If you take a deep look at the relayfs,
> > you may find there are other interfaces/functions no one uses in the
> > kernel tree.
> >
> > I'm now checking this kind of patch in relayfs one by one to avoid
> > such a thing happening. I'm trying to maintain it as much as possible
> > since we internally use it in the networking area to output useful
> > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > is really a wonderful one that helps kernel modules communicate with
> > userspace very efficiently. I'm trying to revive it if I can.
>
> Jason, with all of the respect, if you are interested in keeping things going
> on, please add yourself to the MAINTAINERS. It will makes the users of the
> legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> and you happy.

I didn't subscribe to LKML because they're too many emails everyday.
Because of this, I missed most of changes in relayfs.

Sure, I'm happy to do so, but I'm not sure how/what the detailed
process is here. I would like to ask the core maintainers/developers
in advance.

Any thoughts on this? Andrew, Jens.

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

It's due to the history problem. Back then, developers were trying to
develop various file systems to add more debuginfo. As you may notice,
blktrace is the one which manifests the answer.

>
> > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

On Mon, May 12, 2025 at 2:17 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 12, 2025 at 09:14:56AM +0300, Andy Shevchenko wrote:
> > On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > > Hi All,
> > >
> > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > joining the party late.
> > >
> > > I have a different opinion on this. For me, I'm very cautious about
> > > what those so-called legacy interfaces are and how they can work in
> > > different cases and what the use case might be... There are still a
> > > small number of out-of-tree users like me heavily relying on relayfs
> > > mechanism. So my humble opinion is that if you want to remove
> > > so-called dead code, probably clearly state why it cannot be used
> > > anymore in the future.
> > >
> > > Dr. David, I appreciate your patch, but please do not simply do the
> > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > you may find there are other interfaces/functions no one uses in the
> > > kernel tree.
> > >
> > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > such a thing happening. I'm trying to maintain it as much as possible
> > > since we internally use it in the networking area to output useful
> > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > is really a wonderful one that helps kernel modules communicate with
> > > userspace very efficiently. I'm trying to revive it if I can.
> >
> > Jason, with all of the respect, if you are interested in keeping things going
> > on, please add yourself to the MAINTAINERS. It will makes the users of the
> > legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> > and you happy.
> >
> > 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?
> >
> > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
>
> With the above being said, I am +1 for the patch to stay. Feel free to send
> a revert with a good justification of why it should stay. Note, out-of-tree
> is not enough argument.

Thanks for the vote. Let me seriously think of the possible use case
here. If I find one, I think I would revert it as soon as possible.

Thanks,
Jason

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Andy Shevchenko]

On Mon, May 12, 2025 at 02:53:56PM +0800, Jason Xing wrote:
> On Mon, May 12, 2025 at 2:15 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > >
> > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > joining the party late.
> > >
> > > I have a different opinion on this. For me, I'm very cautious about
> > > what those so-called legacy interfaces are and how they can work in
> > > different cases and what the use case might be... There are still a
> > > small number of out-of-tree users like me heavily relying on relayfs
> > > mechanism. So my humble opinion is that if you want to remove
> > > so-called dead code, probably clearly state why it cannot be used
> > > anymore in the future.
> > >
> > > Dr. David, I appreciate your patch, but please do not simply do the
> > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > you may find there are other interfaces/functions no one uses in the
> > > kernel tree.
> > >
> > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > such a thing happening. I'm trying to maintain it as much as possible
> > > since we internally use it in the networking area to output useful
> > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > is really a wonderful one that helps kernel modules communicate with
> > > userspace very efficiently. I'm trying to revive it if I can.
> >
> > Jason, with all of the respect, if you are interested in keeping things going
> > on, please add yourself to the MAINTAINERS. It will makes the users of the
> > legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> > and you happy.
> 
> I didn't subscribe to LKML because they're too many emails everyday.
> Because of this, I missed most of changes in relayfs.

And how is this relevant to my proposal?

Moreover with `lei` you can filter out from time to time the lore archive for
these, no need to be subscribed and read LKML in full.

> Sure, I'm happy to do so, but I'm not sure how/what the detailed
> process is here. I would like to ask the core maintainers/developers
> in advance.
> 
> Any thoughts on this? Andrew, Jens.

Just send a patch to the LKML which adds a relevant record into MAINTAINERS.
I believe all stakeholders here will be happy to accept that kind of change.

At least you can get my Ack, FWIW (I am not a stakeholder here).

> > 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?
> 
> It's due to the history problem. Back then, developers were trying to
> develop various file systems to add more debuginfo. As you may notice,
> blktrace is the one which manifests the answer.

Then provide a roadmap on the upstreaming the necessary parts. Otherwise
there is no room for a dead code in the Linux kernel. This is the rule:
we do not add one, and we do not leave it dangling after removing the last
user.

> > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Andy Shevchenko]

On Mon, May 12, 2025 at 02:55:45PM +0800, Jason Xing wrote:
> On Mon, May 12, 2025 at 2:17 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, May 12, 2025 at 09:14:56AM +0300, Andy Shevchenko wrote:
> > > On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > > >
> > > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > > joining the party late.
> > > >
> > > > I have a different opinion on this. For me, I'm very cautious about
> > > > what those so-called legacy interfaces are and how they can work in
> > > > different cases and what the use case might be... There are still a
> > > > small number of out-of-tree users like me heavily relying on relayfs
> > > > mechanism. So my humble opinion is that if you want to remove
> > > > so-called dead code, probably clearly state why it cannot be used
> > > > anymore in the future.
> > > >
> > > > Dr. David, I appreciate your patch, but please do not simply do the
> > > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > > you may find there are other interfaces/functions no one uses in the
> > > > kernel tree.
> > > >
> > > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > > such a thing happening. I'm trying to maintain it as much as possible
> > > > since we internally use it in the networking area to output useful
> > > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > > is really a wonderful one that helps kernel modules communicate with
> > > > userspace very efficiently. I'm trying to revive it if I can.
> > >
> > > Jason, with all of the respect, if you are interested in keeping things going
> > > on, please add yourself to the MAINTAINERS. It will makes the users of the
> > > legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> > > and you happy.
> > >
> > > 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?
> > >
> > > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
> >
> > With the above being said, I am +1 for the patch to stay. Feel free to send
> > a revert with a good justification of why it should stay. Note, out-of-tree
> > is not enough argument.
> 
> Thanks for the vote. Let me seriously think of the possible use case
> here. If I find one, I think I would revert it as soon as possible.

Sure, I will be happy to help reviewing such a revert.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

On Mon, May 12, 2025 at 3:22 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, May 12, 2025 at 02:53:56PM +0800, Jason Xing wrote:
> > On Mon, May 12, 2025 at 2:15 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, May 12, 2025 at 09:12:56AM +0800, Jason Xing wrote:
> > > >
> > > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > > joining the party late.
> > > >
> > > > I have a different opinion on this. For me, I'm very cautious about
> > > > what those so-called legacy interfaces are and how they can work in
> > > > different cases and what the use case might be... There are still a
> > > > small number of out-of-tree users like me heavily relying on relayfs
> > > > mechanism. So my humble opinion is that if you want to remove
> > > > so-called dead code, probably clearly state why it cannot be used
> > > > anymore in the future.
> > > >
> > > > Dr. David, I appreciate your patch, but please do not simply do the
> > > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > > you may find there are other interfaces/functions no one uses in the
> > > > kernel tree.
> > > >
> > > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > > such a thing happening. I'm trying to maintain it as much as possible
> > > > since we internally use it in the networking area to output useful
> > > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > > is really a wonderful one that helps kernel modules communicate with
> > > > userspace very efficiently. I'm trying to revive it if I can.
> > >
> > > Jason, with all of the respect, if you are interested in keeping things going
> > > on, please add yourself to the MAINTAINERS. It will makes the users of the
> > > legacy code, Andrew and others, who are doing maintainer's/reviewer's job,
> > > and you happy.
> >
> > I didn't subscribe to LKML because they're too many emails everyday.
> > Because of this, I missed most of changes in relayfs.
>
> And how is this relevant to my proposal?

Well, I was just murmuring.

>
> Moreover with `lei` you can filter out from time to time the lore archive for
> these, no need to be subscribed and read LKML in full.

Oh, thanks for the guidance.

>
> > Sure, I'm happy to do so, but I'm not sure how/what the detailed
> > process is here. I would like to ask the core maintainers/developers
> > in advance.
> >
> > Any thoughts on this? Andrew, Jens.
>
> Just send a patch to the LKML which adds a relevant record into MAINTAINERS.
> I believe all stakeholders here will be happy to accept that kind of change.
>
> At least you can get my Ack, FWIW (I am not a stakeholder here).

Got it. I think I'm going add like this with you acked-by tag:
diff --git a/MAINTAINERS b/MAINTAINERS
index 890699d937b6..208c46416760 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20481,6 +20481,15 @@ L:     linux-wireless@vger.kernel.org
 S:     Orphan
 F:     drivers/net/wireless/rsi/

+RELAY SUBSYSTEM
+M:     Andrew Morton <akpm@linux-foundation.org>
+M:     Jens Axboe <axboe@kernel.dk>
+M:     Jason Xing <kernelxing@tencent.com>
+S:      Maintained
+F:     Documentation/filesystems/relay.rst
+F:     include/linux/relay.h
+F:     kernel/relay.c
+
 REGISTER MAP ABSTRACTION
 M:     Mark Brown <broonie@kernel.org>
 L:     linux-kernel@vger.kernel.org

It would be good if Andrew and Jens approve this first.

>
> > > 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?
> >
> > It's due to the history problem. Back then, developers were trying to
> > develop various file systems to add more debuginfo. As you may notice,
> > blktrace is the one which manifests the answer.
>
> Then provide a roadmap on the upstreaming the necessary parts. Otherwise
> there is no room for a dead code in the Linux kernel. This is the rule:
> we do not add one, and we do not leave it dangling after removing the last
> user.

Got it. Will do that. Thanks for the reminder.

Thanks,
Jason


>
> > > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
>
> --
> With Best Regards,
> Andy Shevchenko
>
>

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Dr. David Alan Gilbert]

* Jason Xing (kerneljasonxing@gmail.com) wrote:
> On Mon, May 12, 2025 at 9:30 AM Dr. David Alan Gilbert
> <linux@treblig.org> wrote:
> >
> > * Jason Xing (kerneljasonxing@gmail.com) wrote:
> > > Hi All,
> >
> > Hi Jason,
> >
> > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > joining the party late.
> > >
> > > I have a different opinion on this. For me, I'm very cautious about
> > > what those so-called legacy interfaces are and how they can work in
> > > different cases and what the use case might be... There are still a
> > > small number of out-of-tree users like me heavily relying on relayfs
> > > mechanism. So my humble opinion is that if you want to remove
> > > so-called dead code, probably clearly state why it cannot be used
> > > anymore in the future.
> >
> > We've got lots of deadcode, why it's dead varies a lot; for example
> > people forgetting to clean it up after other patches etc - so this
> > _could_ be used but hasn't been for well over 7 years.
> >
> > > Dr. David, I appreciate your patch, but please do not simply do the
> > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > you may find there are other interfaces/functions no one uses in the
> > > kernel tree.
> >
> > Actually, that was the only interface in relay that I found unused.
> 
> Not really. More than this single one, say, __relay_write() and
> subbuf_start_reserve()...

Ah, my tools only spot unused symbols, they're header inlines; I've
not found a way to spot those yet.

> > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > such a thing happening. I'm trying to maintain it as much as possible
> > > since we internally use it in the networking area to output useful
> > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > is really a wonderful one that helps kernel modules communicate with
> > > userspace very efficiently. I'm trying to revive it if I can.
> >
> > If you've got a use for that function, then I'm more than happy to suggest
> > just dropping my patch.
> >
> > However, it is a fairly chunky function that is built into distro
> > kernels - so I think it should have a little thought put to it.
> >
> > As I say, if you are using it, it's fine by me just to drop this patch.
> 
> For now, I'm not using it but still considering what the use case
> might be in the future. As I mentioned earlier, I'm trying to make
> relayfs more robust with more realistic functions.
> 
> IMHO, it's not really a dead code to me unless you can clarify why
> it's obsolete instead of claiming "no one is using it".

i'm very gentle about this; I'm not pushing back hard if someone
says actually they want to keep something.

I'd say my 'claim' is fairly good as even you say
  'I'm not using it but still considering..'

You don't need to push back quite as hard on me!

> If you insist
> on the point, then most of relayfs would be removed, which is
> apparently not what I'm wishing for.

You could forgive me for thinking this is unused;
  a) There are no callers in the tree - I can't possibly imagine all
   other trees to check; especially those on someones local disk
   or thoughts still bouncing around in your brain!

  b) There's no listed maintainer, so I can't assume anyone is actively
  working on it

  c) The only changes in years in the tree are cleanups, like strcpy
  variants.

We do have other APIs that people care about and aren't in use;
now if those are nicely thought out APIs etc I think that's fine.
(I've had others say they want to keep some because they like them or
they're part of a well thought out API)

> Probably it will be finally removed, but not at the moment. Evidence
> is still not clear to me :S
> 
> For sure, the last call would be made by Andrew and Jens. Please help
> review this patch one more time. Thanks!

Why don't you add a MAINTAINERS section with you added just as a 
reviewer?   That at least gets you told if someone dares to clean it up
in the future!

Dave

> Thanks,
> Jason
> 
> >
> > Dave
> >
> > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
> > >
> > > Thanks,
> > > Jason
> > --
> >  -----Open up your eyes, open up your mind, open up your code -------
> > / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> > \        dave @ treblig.org |                               | In Hex /
> >  \ _________________________|_____ http://www.treblig.org   |_______/
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

On Mon, May 12, 2025 at 7:50 PM Dr. David Alan Gilbert
<linux@treblig.org> wrote:
>
> * Jason Xing (kerneljasonxing@gmail.com) wrote:
> > On Mon, May 12, 2025 at 9:30 AM Dr. David Alan Gilbert
> > <linux@treblig.org> wrote:
> > >
> > > * Jason Xing (kerneljasonxing@gmail.com) wrote:
> > > > Hi All,
> > >
> > > Hi Jason,
> > >
> > > > I noticed this patch "relay: Remove unused relay_late_setup_files"
> > > > appears in the mm branch already[1], which I totally missed. Sorry for
> > > > joining the party late.
> > > >
> > > > I have a different opinion on this. For me, I'm very cautious about
> > > > what those so-called legacy interfaces are and how they can work in
> > > > different cases and what the use case might be... There are still a
> > > > small number of out-of-tree users like me heavily relying on relayfs
> > > > mechanism. So my humble opinion is that if you want to remove
> > > > so-called dead code, probably clearly state why it cannot be used
> > > > anymore in the future.
> > >
> > > We've got lots of deadcode, why it's dead varies a lot; for example
> > > people forgetting to clean it up after other patches etc - so this
> > > _could_ be used but hasn't been for well over 7 years.
> > >
> > > > Dr. David, I appreciate your patch, but please do not simply do the
> > > > random cleanup work __here__. If you take a deep look at the relayfs,
> > > > you may find there are other interfaces/functions no one uses in the
> > > > kernel tree.
> > >
> > > Actually, that was the only interface in relay that I found unused.
> >
> > Not really. More than this single one, say, __relay_write() and
> > subbuf_start_reserve()...
>
> Ah, my tools only spot unused symbols, they're header inlines; I've
> not found a way to spot those yet.
>
> > > > I'm now checking this kind of patch in relayfs one by one to avoid
> > > > such a thing happening. I'm trying to maintain it as much as possible
> > > > since we internally use it in the networking area to output useful
> > > > information in the hot paths, a little bit like blktrace. BTW, relayfs
> > > > is really a wonderful one that helps kernel modules communicate with
> > > > userspace very efficiently. I'm trying to revive it if I can.
> > >
> > > If you've got a use for that function, then I'm more than happy to suggest
> > > just dropping my patch.
> > >
> > > However, it is a fairly chunky function that is built into distro
> > > kernels - so I think it should have a little thought put to it.
> > >
> > > As I say, if you are using it, it's fine by me just to drop this patch.
> >
> > For now, I'm not using it but still considering what the use case
> > might be in the future. As I mentioned earlier, I'm trying to make
> > relayfs more robust with more realistic functions.
> >
> > IMHO, it's not really a dead code to me unless you can clarify why
> > it's obsolete instead of claiming "no one is using it".
>
> i'm very gentle about this; I'm not pushing back hard if someone
> says actually they want to keep something.
>
> I'd say my 'claim' is fairly good as even you say
>   'I'm not using it but still considering..'
>
> You don't need to push back quite as hard on me!

Oh, sorry, It's absolutely not my intention. I was trying to share my
opinion. No hard feelings;)

>
> > If you insist
> > on the point, then most of relayfs would be removed, which is
> > apparently not what I'm wishing for.
>
> You could forgive me for thinking this is unused;
>   a) There are no callers in the tree - I can't possibly imagine all
>    other trees to check; especially those on someones local disk
>    or thoughts still bouncing around in your brain!
>
>   b) There's no listed maintainer, so I can't assume anyone is actively
>   working on it
>
>   c) The only changes in years in the tree are cleanups, like strcpy
>   variants.
>
> We do have other APIs that people care about and aren't in use;
> now if those are nicely thought out APIs etc I think that's fine.
> (I've had others say they want to keep some because they like them or
> they're part of a well thought out API)

I see what you mean here. Relayfs is a bit special.

>
> > Probably it will be finally removed, but not at the moment. Evidence
> > is still not clear to me :S
> >
> > For sure, the last call would be made by Andrew and Jens. Please help
> > review this patch one more time. Thanks!
>
> Why don't you add a MAINTAINERS section with you added just as a
> reviewer?   That at least gets you told if someone dares to clean it up
> in the future!

Right, thanks for advising. I'm now asking for permission from Andrew and Jens.

Thanks,
Jason

>
> Dave
>
> > Thanks,
> > Jason
> >
> > >
> > > Dave
> > >
> > > > [1]: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything&id=46aa76118ee365c25911806e34d28fc2aa5ef997
> > > >
> > > > Thanks,
> > > > Jason
> > > --
> > >  -----Open up your eyes, open up your mind, open up your code -------
> > > / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> > > \        dave @ treblig.org |                               | In Hex /
> > >  \ _________________________|_____ http://www.treblig.org   |_______/
> --
>  -----Open up your eyes, open up your mind, open up your code -------
> / Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \
> \        dave @ treblig.org |                               | In Hex /
>  \ _________________________|_____ http://www.treblig.org   |_______/

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jens Axboe]

On 5/12/25 1:21 AM, Andy Shevchenko wrote:
> Then provide a roadmap on the upstreaming the necessary parts. Otherwise
> there is no room for a dead code in the Linux kernel. This is the rule:
> we do not add one, and we do not leave it dangling after removing the last
> user.

I don't pay a lot of attention to "roadmaps" - if the code is unused in
the kernel, it should go. Once other codes goes upstream that needs it,
it can get added back as a prep patch. Way too many times I've seen
promises and roadmaps for things that never materialize, and then the
code lingers for years before it's finally deleted.

So I'd say kill it with fire, bring it back if/when needed.

-- 
Jens Axboe

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Christoph Hellwig]

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.

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

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

It seems that turning it back to a filesystem again is the only way to
stop debate, then no one would clean up its dead code and reckon it's
obsolete any more :S

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jens Axboe]

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.

-- 
Jens Axboe

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jason Xing]

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?

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

Re: [PATCH] relay: Remove unused relay_late_setup_files

[Jens Axboe]

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