From owner-freebsd-current@FreeBSD.ORG Tue Aug 15 15:09:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2836316A4DF for ; Tue, 15 Aug 2006 15:09:11 +0000 (UTC) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E35143E5C for ; Tue, 15 Aug 2006 15:08:07 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [172.30.10.238] (unknown [216.239.55.7]) by elvis.mu.org (Postfix) with ESMTP id 43FAE1A3C20; Tue, 15 Aug 2006 08:08:05 -0700 (PDT) Message-ID: <44E1E33A.5030205@FreeBSD.org> Date: Tue, 15 Aug 2006 17:07:38 +0200 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Astrodog References: <20060815141151.15ae4349@Magellan.Leidinger.net> <44E1BD03.2030402@FreeBSD.org> <20060815144625.362bf376@Magellan.Leidinger.net> <44E1C3E4.7080508@FreeBSD.org> <2fd864e0608150607h25244522u74ddfe5ebd7d470c@mail.gmail.com> In-Reply-To: <2fd864e0608150607h25244522u74ddfe5ebd7d470c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Leidinger , current@freebsd.org Subject: Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 15:09:11 -0000 Astrodog wrote: > On 8/15/06, Suleiman Souhlal wrote: > >> >> Alexander Leidinger wrote: >> >> > I already started... and I don't want to commit some parts (the linker >> > stuff which allows to use the module on amd64). >> > >> > It is also not used by default, as long as we have 2.4.2 for the linux >> > version, no new functions will be used by glibc. So there is no change >> > in behavior after the commits. I tested with acroread (which has issues >> > when run with a 2.6.16 compat.linux.osrelease version, where the new >> > functions are used by glibc). >> > >> > So this gives us: >> > - coverity reports for the code *before the end of the SoC* >> >> Why the rush? I'm sure Roman will be around even when the SoC is over. >> >> Also, I'm not asking you to wait a month, just a couple of days until >> more people have had a chance to look at the changes. >> >> It's a bit unreasonable to say "here's a patch, please look at it" and >> commit it less than a day later. >> >> > - no change in behavior in the default case, since the new calls >> > aren't used by glibs as long as... see following entry >> > - easy testing possibility (sysctl compat.linux.osrelease=2.6.16, >> > defaults to 2.4.2) >> > - more eyes on the code >> >> Those are not valid reasons to commit unreviewed and potentially wrong >> changes. >> >> -- Suleiman >> > > Forgive me if I seem to misunderstand things here, but: > > We've had ULE in -RELEASE, even when it was known to be broken. The reason > that was acceptable was its "Opt In" nature. (And, thus the problems > when it > wasn't opt in). The fact that this can be easily turned off, and on would, > in my opinion, make the issue of it being committed pretty irrelevent. That was a mistake, IMHO. > I see this as fairly important code for Linux compat going forward, so a > quicker release to -CURRENT, when it can be disabled, which allows it to be > cleaned up and prepared for the next -RELEASE seems like a good move. > Compare this to some of the audit and bsm bits that got put in, for > example. I am not saying it shouldn't have been committed at all. I'm saying it should have been committed *after* being reviewed. > I don't believe the patch is the "full version".... I'd have to ask Roman > about it. > > Basically, if its wrong, but isn't enabled by default, -CURRENT is as > good a > home as any for this sort of thing, in my opinion. It certainly widens the > pool for testing... > > --- Harrison Grundy > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"