Skip site navigation (1)Skip section navigation (2)
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>