HEADS-UP: starting to commit linuxolator (SoC 2006) changes...

[Suleiman Souhlal]

Astrodog wrote:
> On 8/15/06, Suleiman Souhlal <ssouhlal at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"