-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/27/2014 09:45 AM, Arthur Țițeică wrote:
În ziua de Miercuri 26 Martie 2014, la 19:56:26, Thomas Bächler a scris:
I want to trim our kernel down to what we actually support.
1) Once we agreed to disable one LSM, everyone else said "we can enable LSM XYZ, too". And so we did. Right now, we enable SELinux, SMACK, Tomoyo, AppArmor and Yama, although we don't support the userspace for any of those.
My opinion on this is that the kernel should be the ground on which userspace should always work.
Features should be taken out with bug reports demonstrating breakage in general usage, slowdowns or security risks.
Another important point of view should be the maintenance required to support these seldom used features and I have nothing to comment on this.
Specifically regarding slowdowns, my layman opinion on this is that they are meaningless in the general usage of the -ARCH kernel.
If taking out theoretically useful features out of the kernel means that in the end we gain 2 Mb of free memory or Apache is able to sustain 10500 connections instead of 10000 I personally don't see it as good bargain.
Building a personal or an AUR linux package is easy. Maintaining one is a lot harder. The most important thing that is lost in this process is the community support. One cannot compare the scrutiny and the testing of any AUR linux package with those of the -ARCH kernel.
That being said I'd like to read and help test a before and after kernel in regards to performance or any other concerning factor.
First, +1 for the response. Second, after reading this entire thread, I think it comes down to this: If maintaining the current config with SELinux, SMACK, etc.. support is a significant part of maintaining the kernel package for TB, then that is the argument for ditching it. If you are spending 30% of kernel package maintenance time of this stuff for the benefit of a few users, then it makes sense to drop it and let whoever uses it maintain that config, and possibly add an EXTRA/AUR linux-SELinux-kernel-config.tar.xz package (and -SMACK, -LSM) to make that config available so that every user who wants to build the kernel with that support does not have to reinvent the wheel for each rebuild. I do not know what level of effort is involved in maintaining that config, but if doing so requires significant effort, that effort should be borne by those making use of it and not TB. If removal is needed due to claimed performance issues, then it takes test-case evidence to support that. Otherwise, the reasoning is no better than search location for MH370. I support TB's effort to trim down the config, but if providing the current options is no-cost from a maintenance, security or performance standpoint, then there is no reason not to provide the capability in the kernel. I think this discussion is well worth the effort to identify what in the current config has a cost (in maintenance, security or performance) that outweighs the benefit the feature provides. Those are the parts of the config that should be trimmed and moved to user-maintenance. - -- David C. Rankin, J.D.,P.E. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM8h3gACgkQZMpuZ8CyrcjpLwCeNR/NE6ya1KekdtzdgaiCRJY6 BoEAn23SlMmF6DiicHjTlK/h50ApV5WV =aHYI -----END PGP SIGNATURE-----