Re: HEADS UP: caution required with updates using custom kernels

On Fri, Jun 24, 2016 at 03:24:21PM -0700, Chris H wrote:
> On Fri, 24 Jun 2016 15:51:11 +0000 Brooks Davis <brooks_at_freebsd.org> wrote
> 
> > On Fri, Jun 24, 2016 at 06:00:19AM +0200, O. Hartmann wrote:
> > > Am Thu, 23 Jun 2016 21:07:51 +0000
> > > Brooks Davis <brooks_at_freebsd.org> schrieb:
> > > 
> > > > Kernel config minimalists and those running aarch64 and riscv systems
> > > > will want to head this UPDATING message.
> > > > 
> > > > In practice, if you're fairly up to date, doing installworld before
> > > > installkernel will also work (I've tested that case from ALPHA4), but is
> > > > always somewhat risky.
> > > > 
> > > > -- Brooks
> > > > 
> > > > ----- Forwarded message from Brooks Davis <brooks_at_FreeBSD.org> -----
> > > > 
> > > > Date: Thu, 23 Jun 2016 21:02:05 +0000 (UTC)
> > > > From: Brooks Davis <brooks_at_FreeBSD.org>
> > > > To: src-committers_at_freebsd.org, svn-src-all_at_freebsd.org,
> > > >     svn-src-head_at_freebsd.org
> > > > Subject: svn commit: r302152 - head
> > > > 
> > > > Author: brooks
> > > > Date: Thu Jun 23 21:02:05 2016
> > > > New Revision: 302152
> > > > URL: https://svnweb.freebsd.org/changeset/base/302152
> > > > 
> > > > Log:
> > > >   Add an UPDATING entry for the pipe() -> pipe2() transition.
> > > >   
> > > >   Approved by:    re (gjb)
> > > >   Sponsored by:    DARPA, AFRL
> > > > 
> > > > Modified:
> > > >   head/UPDATING
> > > > 
> > > > Modified: head/UPDATING
> > > >
> > > >
> =============================================================================
> > > > = --- head/UPDATING    Thu Jun 23 20:59:13 2016    (r302151)
> > > > +++ head/UPDATING    Thu Jun 23 21:02:05 2016    (r302152)
> > > > _at__at_ -31,6 +31,14 _at__at_ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11
> > > >      disable the most expensive debugging functionality run
> > > >      "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> > > >  
> > > > +20160622:
> > > > +    The the libc stub for the pipe(2) system call has been replaced with
> > > > +    a wrapper which calls the pipe2(2) system call and the pipe(2) is
> > > > now +    only implemented by the kernels which include "options
> > > > +    FREEBSD10_COMPAT" in their config file (this is the default).
> > > > +    Users should ensure that this option is enabled in their kernel
> > > > +    or upgrade userspace to r302092 before upgrading their kernel.
> > > > +
> > > >  20160527:
> > > >      CAM will now strip leading spaces from SCSI disks' serial numbers.
> > > >      This will effect users who create UFS filesystems on SCSI disks
> > > >      using > > 
> > > > 
> > > > ----- End forwarded message -----
> > > 
> > > Is this showing up, when one doesn't have the expected COMPAT_FREEBSD10 in
> > > kernel and updated kernel __before___ world?:
> > 
> > You must include COMPAT_FREEBSD10 or have a new userspace.  Otherwise
> > things like your shell are unlikely to work.
> > 
> Hi. I don't see any indication of why this change was required
> (the obsolescence of pipe(2))
> Can you elaborate a little, please?

pipe(2) had an unnecessarily odd calling convention (ignoring the
argument the user thought they were passing and returning the two file
descriptors via the two return registers).  This required machine
dependent assembly for every target and special handling in tracing
tools (ktrace, dtrace, etc).  On 64-bit platforms, pipe(2)'s
implementation is the only reason the two-register return model needs to
exist at all (on 32-bit platforms it allows off_t to be returned from
lseek).

I'll own that my timing on this was terrible.  In an ideal world the
user space change would have gone in months ago with the COMPAT10 change
now.  Unfortunately I only realized this was something that made sense
while at BSDCan.

Strictly speaking, this change isn't required, but making it making
it now allows aarch64 and riscv to be free of this dubious calling
convention and tidying up libc a bit.  Opportunities to remove cruft at
the scale of syscall interfaces are rare so I've been pushing to clean
up aarch64 and riscv while we have a chance.

-- Brooks