From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Peter Taraba <peter.schuster.taraba@gmail.com>
Cc: corbet@lwn.net, akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib: add statsort(), a distribution/bucket sort
Date: Mon, 10 Aug 2026 18:22:56 +0800 [thread overview]
Message-ID: <anmmgDDQ0r2vaOty@google.com> (raw)
In-Reply-To: <20260805184440.12964-1-peter.schuster.taraba@gmail.com>
Hi Peter,
On Wed, Aug 05, 2026 at 11:44:40AM -0700, Peter Taraba wrote:
> Hi Jon & others,
>
> >> OK, good luck with that. The kernel does not add code to support
> >> proprietary projects.
>
> I want this idea to go to Linux Kernel and not be proprietary, but I
> want to make sure Microsoft and Facebook copy cats don't import this
> idea into their Windows and their other own operating systems and
> continue forcing their ways on others thanks to their still large
> user base. I am not worried about Google, as it's in their best
> interest to get this code into Linux as they are heavy users &
> contributors to Linux.
>
> There are at least three future scenarios:
> 1. Someone gives me 750$ + 250$ for filing preliminary patent, so there
> would be a trap to slow down Microsoft and Facebook and I will file
> prelimiary patent with Linux community, wait for a week for dust to
> settle and share my idea.
> 2. Someone gives a seed to my start-up Milky Winf:
> https://temp-qiwnvtinynzgwimacpcb.webadorsite.com/
> and as soon as the invetment hits my bank account, I will share my idea
> on this thread and let Linux community deal with Microsoft and Facebook.
> 3. Work around and let this idea live on my off-internet laptop without
> wifi and network card...
>
> >> Feedback is what you are getting, but you seem remarkably uninterested
> >> in it.
>
> I always appreciate feedback especially from Linux veterans :). I am
> answering and we are still having a discussion, so I do not really
> understad why you believe I am not interested in yours and others
> opinions.
I think the reason Jon felt you were ignoring feedback is that you were
explicitly told the kernel does not accept code without an in tree
user, yet you seemed determined to upstream your code while keeping
your use case a secret. To get this merged, you need to submit the code
that actually consumes this API together as a single patchset. Adding a
new API with no existing callers is an automatic NAK in almost all
cases.
Additionally, why introduce a completely new API instead of modifying
the existing sort()?
Performance is not the only consideration for sort() in the kernel. The
kernel currently uses heapsort not because it's the fastest, but
because of other critical constraints. It requires only O(1) extra
memory, which means we don't have to worry about stack overflows. There
are also scenarios where sorting is needed early in the boot process
before the memory allocator is fully initialized, meaning kmalloc()
cannot be used.
Your sorting method appears to be specifically tailored for 64 bit
integer keys. This is exactly why knowing the "user" is so important:
the community needs to evaluate what specific in kernel scenario is so
heavily bottlenecked by sorting performance that it justifies merging
and maintaining a specialized, extra API, rather than simply relying on
(or improving) the existing sort().
Regards,
Kuan-Wei
>
> >> If you want to contribute to a community, you need to spend some time
> >> understanding how that community works. It is not just by chance that
> >> this project remains vital after all these years. You are asking us to
> >> take on a chunk of code that we will have to maintain indefinitely; we
> >> have learned not to do that without good reason.
>
> Maybe you should look up definition of word Liberty and how it aligns
> with Linux community. But feel free to ignore me if you wish to do so.
>
> >> You don't get to tell me what I should do, sorry.
>
> I never force anyone to do anything unless they want to do it themselves. Don't
> expect me to force you into anything today, nor in future days.
>
> >> The community's rules require disclosure of LLM use. Many first-time
> >> contributors fail to do that, and the reason is often ignorance of the
> >> rules; once informed, they play along. The question is anything but
> >> useless.
>
> People can lie, so what's the point:
> https://randommathguystfu.blogspot.com/2026/07/who-steals-first-not-who-actually.html
>
> >> Plus, it seems clear that you have answered it.
>
> I will cite David Archuleta's song's lyrics 'OK, all right'
>
> Cheers & Queers,
> Peter
>
next prev parent reply other threads:[~2026-08-10 10:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMKTnsb-PZ7_4Zd1ZAtmSWnTk8vyoP07WZUDsLuZ21j7OawQ9g@mail.gmail.com>
2026-08-05 0:35 ` [PATCH] lib: add statsort(), a distribution/bucket sort Andrew Morton
2026-08-05 0:47 ` Peter Taraba
2026-08-05 14:29 ` Jonathan Corbet
2026-08-05 15:47 ` Peter Taraba
2026-08-05 16:39 ` Jonathan Corbet
2026-08-05 18:44 ` Peter Taraba
2026-08-10 10:22 ` Kuan-Wei Chiu [this message]
2026-08-10 13:24 ` Peter Taraba
2026-08-10 15:09 ` Bradley Morgan
2026-08-10 15:59 ` Peter Taraba
2026-08-10 16:07 ` Bradley Morgan
2026-08-04 23:34 Peter Taraba
2026-08-04 23:58 ` Andrew Morton
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=anmmgDDQ0r2vaOty@google.com \
--to=visitorckw@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=peter.schuster.taraba@gmail.com \
/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