Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
I wonder if it is correct to add new syscalls, which actually changes the kernel features, in stable releases, as it might confuse downstream developers because they may assume the existence of a certain feature after a certain version.
Cheers,
Miao Wang
Hi!
I wonder if it is correct to add new syscalls, which actually changes the kernel features, in stable releases, as it might confuse downstream developers because they may assume the existence of a certain feature after a certain version.
Just a side note, one thing I've learned by maintaining the Linux Test Project is that the kernel version is a lie. You should not use the kernel version for anything, never. All distributions rutinely backport various new functionalities to older kernels and only reliable way how to make sure something is implemented is to call the syscall and check the return value.
That being said I have no idea what rules apply to stable trees.
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
I wonder if it is correct to add new syscalls, which actually changes the kernel features, in stable releases, as it might confuse downstream developers because they may assume the existence of a certain feature after a certain version.
Version numbers should never be used to be checked for anything as they are only a "moment in time" stamp. They do not reflect features or capabilities or anything else.
Test for functionality if you want to check for something, that's the only way it will ever work on all of the variants of different "enterprise" kernels.
thanks,
greg k-h
Hi,
2024年8月20日 21:36，Greg Kroah-Hartman gregkh@linuxfoundation.org 写道：
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
Thanks for your explanation. I totally understand the necessity of re-introducing thees two syscalls. I just wonder whether there is any limitation on what can be included in to the stable trees. If there was no limitation, theoretically, I could also maintain a so-called stable tree by applying all the patches from torvalds' tree, except those that bumps the version number. Apparently such a "stable" tree is far from stable.
I wonder if it is correct to add new syscalls, which actually changes the kernel features, in stable releases, as it might confuse downstream developers because they may assume the existence of a certain feature after a certain version.
Version numbers should never be used to be checked for anything as they are only a "moment in time" stamp. They do not reflect features or capabilities or anything else.
I agree with you and Cyril on the version numbers, recalling that kernels on RHEL numbered on 3.10 contains various new features.
Test for functionality if you want to check for something, that's the only way it will ever work on all of the variants of different "enterprise" kernels.
Thanks again for your quick reply.
thanks,
greg k-h
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
Hi,
2024年8月20日 21:36，Greg Kroah-Hartman gregkh@linuxfoundation.org 写道：
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
Thanks for your explanation. I totally understand the necessity of re-introducing thees two syscalls. I just wonder whether there is any limitation on what can be included in to the stable trees. If there was no limitation, theoretically, I could also maintain a so-called stable tree by applying all the patches from torvalds' tree, except those that bumps the version number. Apparently such a "stable" tree is far from stable.
Or you could do the opposite, something that I have seen vendors do, and just bump the kernel version number to try to "claim" they updated their kernel to a more secure one (i.e. one that fixed loads of known issues), but they really didn't.
Either way, it's your kernel, you are free to do whatever you want with it, have fun! :)
greg k-h
On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
Hi,
2024?8?20? 21:36,Greg Kroah-Hartman gregkh@linuxfoundation.org ??:
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
Thanks for your explanation. I totally understand the necessity of re-introducing thees two syscalls. I just wonder whether there is any limitation on what can be included in to the stable trees. If there was no limitation, theoretically, I could also maintain a so-called stable tree by applying all the patches from torvalds' tree, except those that bumps the version number. Apparently such a "stable" tree is far from stable.
Or you could do the opposite, something that I have seen vendors do, and just bump the kernel version number to try to "claim" they updated their kernel to a more secure one (i.e. one that fixed loads of known issues), but they really didn't.
Some of those who do that don't even notice what they're missing. I've seen some BSP kernels "forward-ported" by merging the next bunch of stable versions, trying to fix rejects by hand with the usual ratio of failures, but after that since that version is part of the history, it's impossible to figure what's really missing or not. Some people don't seem to realize that *merging* code can actually result in *removing* fixes. So they don't even need cheat on their versions, they're genuinely believing they're OK... which is worse!
Willy
2024年8月20日 23:05，Willy Tarreau w@1wt.eu 写道：
On Tue, Aug 20, 2024 at 10:00:35PM +0800, Greg Kroah-Hartman wrote:
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
Hi,
2024?8?20? 21:36,Greg Kroah-Hartman gregkh@linuxfoundation.org ??:
On Tue, Aug 20, 2024 at 09:19:04PM +0800, Miao Wang wrote:
Hi, Greg
I saw you have included commit 7697a0fe0154 ("LoongArch: Define __ARCH_WANT_NEW_STAT in unistd.h") in your stable trees, which actually introduced new sys calls newfstatat and fstat to Loongarch.
See the documentation in that commit for why it was done.
Thanks for your explanation. I totally understand the necessity of re-introducing thees two syscalls. I just wonder whether there is any limitation on what can be included in to the stable trees. If there was no limitation, theoretically, I could also maintain a so-called stable tree by applying all the patches from torvalds' tree, except those that bumps the version number. Apparently such a "stable" tree is far from stable.
Or you could do the opposite, something that I have seen vendors do, and just bump the kernel version number to try to "claim" they updated their kernel to a more secure one (i.e. one that fixed loads of known issues), but they really didn't.
Some of those who do that don't even notice what they're missing. I've seen some BSP kernels "forward-ported" by merging the next bunch of stable versions, trying to fix rejects by hand with the usual ratio of failures, but after that since that version is part of the history, it's impossible to figure what's really missing or not. Some people don't seem to realize that *merging* code can actually result in *removing* fixes. So they don't even need cheat on their versions, they're genuinely believing they're OK... which is worse!
Willy
Thank you all for sharing experiences with vendors messing up kernel version numbers.
However, my original question is whether it is expected to include new syscalls in kernel stable tree. According to the document "stable-kernel- rules", if I'm interpreting it correctly, I expect only bug fixes and small driver enhancements from stable releases. I understand the patch in question is actually introducing new syscalls, which is beyond my expectation. So I wonder the consideration of including this patch in stable releases.
Cheers,
Miao Wang
On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
However, my original question is whether it is expected to include new syscalls in kernel stable tree. According to the document "stable-kernel- rules", if I'm interpreting it correctly, I expect only bug fixes and small driver enhancements from stable releases. I understand the patch in question is actually introducing new syscalls, which is beyond my expectation. So I wonder the consideration of including this patch in stable releases.
When you maintain stable software you quickly realize that everything is not just pure white or black but a shade of gray and that if it can be considered as a bug to miss a syscall in certain environments for example, then it can become a valid fix to add it. I don't have any opinion on this particular one, but since your question is broader I'm trying to explain.
Different people have different expectations about what needs to be fixed, that's even why some people will choose a distro over another one (prefer to fix only critical bugs over fixing all bugs for example), but there's no point restarting a philosophical on this topic which has already been rehashed too many times in the past.
As a rule of thumb, just keep in mind that anything that needs to get fix will eventually be fixed.
Thanks, Willy
2024年8月21日 02:30，Willy Tarreau w@1wt.eu 写道：
On Wed, Aug 21, 2024 at 12:09:41AM +0800, Miao Wang wrote:
However, my original question is whether it is expected to include new syscalls in kernel stable tree. According to the document "stable-kernel- rules", if I'm interpreting it correctly, I expect only bug fixes and small driver enhancements from stable releases. I understand the patch in question is actually introducing new syscalls, which is beyond my expectation. So I wonder the consideration of including this patch in stable releases.
When you maintain stable software you quickly realize that everything is not just pure white or black but a shade of gray and that if it can be considered as a bug to miss a syscall in certain environments for example, then it can become a valid fix to add it. I don't have any opinion on this particular one, but since your question is broader I'm trying to explain.
Different people have different expectations about what needs to be fixed, that's even why some people will choose a distro over another one (prefer to fix only critical bugs over fixing all bugs for example), but there's no point restarting a philosophical on this topic which has already been rehashed too many times in the past.
As a rule of thumb, just keep in mind that anything that needs to get fix will eventually be fixed.
Many thanks for your explanation!
Cheers,
Miao Wang
Thanks, Willy
On Tue, Aug 20, 2024 at 09:49:59PM +0800, Miao Wang wrote:
I agree with you and Cyril on the version numbers, recalling that kernels on RHEL numbered on 3.10 contains various new features.
Some enterprise kernel versions have also been known to completely take code whole from some subsystem (like, for example, a file system like ext4 or xfs) from much newer upstream kernel version and backport it into a very old "enterprise" kernel, with massive work to deal with the dependencies that might be needed by the newer code, and additional massive work so that structures and function signatures stay the same so that binary out-of-tree kernel modules can continue to load on that "stable" enterprise kernel.
That might take huge amounts of effort from a quality assurance perspective, but that's might some enterprise customers are willing to pay $$$$ for that frankenkernel and support for that frankenkernel....
This is also why when I get a bug report relating a distro kernel, I tell bug reporters to go back to the distro for support. Basically, you can't really take anything for granted when you're dealing with a non-upstream kernel, and that includes the version number. Personally, I think this is a really bad idea, but distros and their customers have the freedom to do what they want. And this is why those customers pay the distro the big bucks. :-)
- Ted
linux-stable-mirror@lists.linaro.org
-
Cyril Hrubis -
Greg Kroah-Hartman -
Miao Wang -
Theodore Ts'o -
Willy Tarreau