On Thu, 04 Nov 2004 13:15:44 +0000, Luke Kenneth Casson Leighton wrote: > On Thu, Nov 04, 2004 at 01:02:35AM -0600, Manoj Srivastava wrote: >> On Wed, 03 Nov 2004 21:15:38 -0500, Colin Walters <[EMAIL PROTECTED]> said: >> >> > On Wed, 2004-11-03 at 19:21 +0000, Dhruv Gami wrote: >> >> Personally, i would prefer to have those two tarballs available. I >> >> know most people using SELinux are familiar with patching the >> >> kernel, and are generally familiar with how Linux works and know >> >> their way around on a Linux system. >> >> > But moving forward, we don't want people to have to patch their >> > kernel or utilities. >> >> Moving waaay forward. I asked the Debian kernel team to >> consider compiling in SELinux (perhaps disabled by default, for >> starters), and was told that that is not going to fly because of >> "significant performance hit" one takes by compiling SELinux in. I >> did not have any data to refute the claim, so that is where we sit. >
Manoj, if you're referring to our conversation earlier on IRC, I said that I have no personal interest in selinux, but I had no problems with it being included as long as it's not a significant performance hit. I requested that you take it up on the debian-kernel list, though. That request still stands; the kernel team is not a single person, nor is it comprised an IRC channel. > i had a bun-fight with the people who have taken over from herbert: at > the point where i told them that recompiling applications to be > optimised like yoper and gentoo distributions gives back performance > far in excess of that lost by selinux, i stopped hearing back from > them. > I assume you're referring to #249510, in which Christoph mentioned it was a 5% performance penalty. That's significant, especially for people who don't care about selinux. Your argument of "well it's not 20%, is it?" is bogus; throwing features into the kernel, each having a 5% performance penalty hit, quickly add up. Furthermore, this isn't even going to be considered until post-sarge, so there's little point arguing about it now. Just like we've told the PAX people (who, quite frankly, interest me more than the selinux people); provide solid benchmarks showing exactly how little of a performance hit the feature is, and we'll be more likely to include it. Without hard data, all you have are guesses (2%, 5%, hell, it could be 20% for all we know. List your sources). And yes, different compilers may compile code that runs faster; that's not news. That does not mean we're going to slow other parts of the system down to balance that out, if we obtain any speed benefits with gcc-3.4.
