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