cvs commit: src/sys/alpha/osf1 osf1_misc.csrc/sys/amd64/linux32 src/sys/compat/linuxprocfs_status.c src/sys/kern init_main.c ...

[Scott Long]

Wilko Bulte wrote:
> On Mon, Feb 28, 2005 at 02:07:52PM -0700, Scott Long wrote..
> 
>>David O'Brien wrote:
>>
>>>On Mon, Feb 28, 2005 at 03:09:56PM -0500, John Baldwin wrote:
>>>
>>>
>>>>On Monday 28 February 2005 04:26 am, David E. O'Brien wrote:
>>>>
>>>>
>>>>>obrien      2005-02-28 09:26:13 UTC
>>>>>
>>>>>FreeBSD src repository
>>>>>
>>>>>Modified files:        (Branch: RELENG_5)
>>>>>  sys/alpha/osf1       osf1_misc.c
>>>>>  sys/amd64/linux32    linux32_machdep.c
>>>>>  sys/compat/freebsd32 freebsd32_misc.c
>>>>>  sys/compat/linux     linux_misc.c
>>>>>  sys/compat/svr4      svr4_misc.c
>>>>>  sys/fs/procfs        procfs_status.c
>>>>>  sys/kern             init_main.c kern_acct.c kern_clock.c
>>>>>                       kern_exit.c kern_proc.c kern_resource.c
>>>>>                       kern_synch.c kern_time.c subr_trap.c
>>>>>                       tty.c
>>>>>  sys/sys              proc.h resourcevar.h syscallsubr.h
>>>>>Log:
>>>>>MFC: Rework how we store process times in the kernel such that we 
>>>>>always
>>>>>store the raw values including for child process statistics and only
>>>>>compute the system and user timevals on demand.
>>>>>(See the 2004-10-05 18:51:12 UTC jhb commit for full details.)
>>>>
>>>>NO!!! This breaks the ABI for all kernel modules.  I would have already 
>>>>MFC'd it first if not for that.  You should have asked me before MFcing 
>>>>this. :(
>>>
>>>
>>>There are tons of "MFC after:" commits that people never got around to
>>>MFC'ing.  I'm doing those now, and this was one of them.  I'm seriously
>>>concerned that we don't diverge 6-CURRENT/5-STABLE as we did in the
>>>4.x/3.x days.
>>>
>>>We've already discussed dealing this commit on IRC, so I'll end here.
>>>
>>
>>The "MFC After' messages are merely a convenience reminder.  You should 
>>not be interpreting them as compulsory.  We had this discussion years 
>>ago and it's no different now.
>>
>>Scott
> 
> 
> Sounds like adding a "Do Not MFC, will break ABI" is called for in some
> circumstances.
> 
> 

Again, it's just a helpful reminder.  I don't think it needs to be
over-engineered.  In this particular case, the author discovered after
the commit was made that it would break the ABI.  That kind of thing
happens a lot; a change is made to HEAD with the intention of
backporting it, but it's later discovered to be inappropriate or
incorrect, and adjustments are made.  We're engineers, not robots, and
we need to be able to think critically and act with flexibility.

Scott