On 2021/6/21 下午6:56, Leizhen (ThunderTown) wrote:
> Hello, Qu:
>
> My contributions to the kernel in the past have mainly been on optimizing the performance of the ARM64 SMMU driver,
> including the iova optimization, strict mode optimization, and the lazy mode optimization. Also working on the
> development of some ARM SoC drivers.
You indeed have done solid contribution to the kernel in the past, thus
better could have been done.
>
> When time and effort is allowed, I also contribute to other modules of Linux kernel, trying to find something can be
> improved, and some cleanup work is being done.
I'm not saying cleanup is not important, in fact we have routinely
cleanups of typos/grammar for btrfs. (And I guess mostly caused by myself?)
Please at least merge all those small fixes into a larger patchset, and
with a good cover letter to explain the reason (and auto-tool to do the
change if possible) for all the involved maintainers, so that all of us
are on the same page.
>
> In the future, I will continue to make more and more important contributions to the Linux community.
Even without checking the git log, I can easily think of some big
contributions from your employer, like EROFS and F2FS.
Thus I don't have any doubt about that.
If you guys just want more ideas, there are tons of better things can be
done, for both newbie and veteran, which IMHO can benefit everyone in
the community:
- Better kernel CI/Zero-day testing
One of the better example is Intel LKP, it caught quite some bugs.
(although sometimes not that reproducible)
If you guys could have such facility running for not only upstream
kernels but also maintainers' trees, I have no doubt it will be well
received.
- BUG_ON() removal
I'm pretty sure there are quite some code using BUG_ON() to handle
errors, especially for -ENOMEM (just handled a dozen in btrfs).
Can't imagine a maintainer don't like this (of course with proper
commit message)
- Error injection tests
Especially when combined with above BUG_ON() removal.
Any everyone can also learn some tricks from BCC community.
- Better code refactor for super long parameter lists/super deep loops
I'm definitely not referring functions like submit_extent_page().
Although if anyone has better way to refactor such functions, it would
definitely be a good move.
- More comprehensive metadata check for various filesystems
Not sure about other fses, as they have much less metadata usage.
But we have almost member by member check for all metadata, it may
be an interesting idea to enhance other filesystems too.
- More upstream phone/tablet support
Especially for guys even running upstream kernel on RPI CM4 like me,
more ARM devices with upstream kernel support will just be more
happiness.
Not to mention this also means super long time support, way longer
than the lifespan of those devices.
It's super sad to see just less than a dozen phones/tablets got
upstream kernel support.
Even more frustrating that those mainlined devices are already pretty
old and slow for today's standard.
If you guys can change the trend, it would be wonderful.
- More testing on extra page size
Well, this is more or less related to my personal work, testing
btrfs subpage support on 64K page sized Aarch64 platforms.
Despite of my impure motivation, tests on new page size would
definitely help everyone.
(Looking at some M1 chips which doesn't even support 64K page size
at all)
Thanks,
Qu
所以这件事到这里,在“事发地”都发展的挺好挺理性了,可以说这件事如果下面吃瓜群众和媒体平台们不再继续传播的话,当事人们都快通过简单的3封邮件和解了(除非有人过去添油加醋)。所以这里我再次呼吁,让这件事回归它本来的地方,没必要成为一个出圈话题而引来舆论的发酵。
作者:醉卧沙场
链接:https://www.zhihu.com/question/466111598/answer/1951896502
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
flydo 发表于 2021-6-22 11:53
https://lkml.org/lkml/2021/6/21/314
首先,只是一个叫“Leizhen”修复的一些文字上面的错误,并不是所 ...
非法用户 发表于 2021-6-22 13:14
这个并不是偶然事件。注意邮件这一段,
The last time we got some similar patches from the same co ...
EmergentRecruit 发表于 2021-6-22 09:46
楼主发帖可不是要跟你讨论新不新鲜的问题,你自己往这上面带节奏
先把自己的理解能力提高
flydo 发表于 2021-6-22 11:53
https://lkml.org/lkml/2021/6/21/314
首先,只是一个叫“Leizhen”修复的一些文字上面的错误,并不是所 ...
But the mail address makes me cautious, "@huawei.com".
The last time we got some similar patches from the same company, doing
something harmless "cleanup". But those "fixes" are also useless.
This makes me wonder, what is really going on here.
非法用户 发表于 2021-6-21 18:17
From Qu Wenruo
Subject Please don't waste maintainers' time on your KPI grabbing patches (AKA, don ...
通信人家园 (https://www.txrjy.com/) | Powered by C114 |