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

On Fri, 24 Jun 2016 22:50:34 +0000 Brooks Davis <brooks_at_freebsd.org> wrote

> 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
Ahh. Pity that pipe(2) couldn't remain, well, pipe(2).
None the less, thank you very much for such an informative
reply, Brook. Greatly appreciated! Also, thanks for taking the
time to fix it!

--Chris

--