Date: Tue, 15 Aug 2006 17:07:38 +0200 From: Suleiman Souhlal <ssouhlal@FreeBSD.org> To: Astrodog <astrodog@gmail.com> Cc: Alexander Leidinger <Alexander@leidinger.net>, current@freebsd.org Subject: Re: HEADS-UP: starting to commit linuxolator (SoC 2006) changes... Message-ID: <44E1E33A.5030205@FreeBSD.org> In-Reply-To: <2fd864e0608150607h25244522u74ddfe5ebd7d470c@mail.gmail.com> References: <20060815141151.15ae4349@Magellan.Leidinger.net> <44E1BD03.2030402@FreeBSD.org> <20060815144625.362bf376@Magellan.Leidinger.net> <44E1C3E4.7080508@FreeBSD.org> <2fd864e0608150607h25244522u74ddfe5ebd7d470c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Astrodog wrote: > On 8/15/06, Suleiman Souhlal <ssouhlal@freebsd.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44E1E33A.5030205>