OpenBSD src changes summary for 2016-10-27
==========================================

distrib/sets                            lib/libc
sys/arch/alpha/alpha                    sys/arch/alpha/conf
sys/arch/amd64/conf                     sys/arch/armv7/conf
sys/arch/hppa/conf                      sys/arch/i386/conf
sys/arch/landisk/conf                   sys/arch/loongson/conf
sys/arch/luna88k/conf                   sys/arch/macppc/conf
sys/arch/mips64/mips64                  sys/arch/octeon/conf
sys/arch/octeon/octeon                  sys/arch/sgi/conf
sys/arch/sgi/sgi                        sys/arch/socppc/conf
sys/arch/sparc64/conf                   sys/dev/pci
sys/dev/pv                              sys/dev/usb
sys/kern                                sys/net
usr.bin/colrm                           usr.bin/cvs
usr.bin/sndiod                          usr.sbin/bgpd
usr.sbin/config                         usr.sbin/tcpdump

== distrib =========================================================== 01/05 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib

sets

  ~ lists/base/md.alpha                   ~ lists/base/md.amd64
  ~ lists/base/md.armv7                   ~ lists/base/md.hppa
  ~ lists/base/md.i386                    ~ lists/base/md.landisk
  ~ lists/base/md.loongson                ~ lists/base/md.luna88k
  ~ lists/base/md.macppc                  ~ lists/base/md.octeon
  ~ lists/base/md.sgi                     ~ lists/base/md.socppc
  ~ lists/base/md.sparc64                 ~ lists/comp/mi

  > sync (deraadt@)

== lib =============================================================== 02/05 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib

libc

  ~ sys/pledge.2                          

  > For consistency, allow symlinkat(2) in the same way as symlink(2);
  > no need to wait until the first program using it breaks...
  > "could make sense" semarie@ (and thanks for the cluestick)
  > OK deraadt@ (schwarze@)

== sys =============================================================== 03/05 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys

arch/alpha/alpha

  ~ cpu.c                                 

  > increment ncpus when a cpu is attached, not when its booted.
  > fixes percpu allocations, like visa@ just did on mips64. (dlg@)

  ~ cpu.c                                 

  > revert 1.41 now that subr_percpu is using ncpusfound instead of ncpus.
  > (dlg@)

arch/alpha/conf

  ~ Makefile.alpha                        

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/amd64/conf

  ~ Makefile.amd64                        

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/armv7/conf

  ~ Makefile.armv7                        

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/hppa/conf

  ~ Makefile.hppa                         

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/i386/conf

  ~ Makefile.i386                         

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/landisk/conf

  ~ Makefile.landisk                      

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/loongson/conf

  ~ Makefile.loongson                     

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/luna88k/conf

  ~ Makefile.luna88k                      

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/macppc/conf

  ~ Makefile.macppc                       

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/mips64/mips64

  ~ cpu.c                                 

  > Revert previous `ncpus' change because the percpu code now works
  > without it. (visa@)

arch/octeon/conf

  ~ Makefile.octeon                       

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/octeon/octeon

  ~ machdep.c                             

  > Revert previous `ncpus' change because the percpu code now works
  > without it. (visa@)

arch/sgi/conf

  ~ Makefile.sgi                          

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/sgi/sgi

  ~ ip27_machdep.c                        ~ ip30_machdep.c

  > Revert previous `ncpus' change because the percpu code now works
  > without it. (visa@)

arch/socppc/conf

  ~ Makefile.socppc                       

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

arch/sparc64/conf

  ~ Makefile.sparc64                      

  > We don't generate an eddep script for kernel builds nowadays. The last
  > reference to eddep in the kernel Makefile I could find is in 4.3BSD,
  > released some 30 years ago.
  > ok tb millert (natano@)

dev/pci

  ~ if_em.c                               ~ if_ix.c
  ~ if_em.h                               

  > tell ix and em to use 2k+ETHER_ALIGN clusters for rx on all archs.
  > this means that the ethernet header and therefore its payload will
  > be aligned correctly for the stack. without this em and ix are
  > sufferring a 30 to 40 percent hit in forwarding performance because
  > the ethernet stack expects to be able to prepend 8 bytes for an
  > ethernet header so it can gaurantee its alignment. because em and
  > ix only had 6 bytes where the ethernet header was, it always prepends
  > an mbuf which turns out to be expensive. this way the prepend will
  > be cheap because the 8 byte space will exist.
  > 2k+ETHER_ALIGN clusters will end up using the newly created mcl2k2
  > pool.
  > the regression was isolated and the fix tested by hrvoje popovski.
  > ok mikeb@ (dlg@)

dev/pv

  ~ hyperv.c                              

  > Improve channel ring locking strategy
  > Make sure to hold the ring buffer lock for the complete duration
  > of a channel ring I/O operation.  For read operations this means
  > peeking and reading is done uninterrupted and for both reads and
  > writes this places the buffer space availability check under the
  > same lock as well. (mikeb@)

  ~ pvbus.c                               

  > vmm is also available on i386 now, so don't restrict it to amd64.
  > OK mikeb@ mlarkin@ (reyk@)

dev/usb

  ~ uaudio.c                              

  > Uniformize debug printfs, by using consistently __func__ everywhere.
  > From Michael W. Bombardieri <mb at ii.net> (ratchov@)

kern

  ~ uipc_mbuf.c                           

  > add a new pool for 2k + 2 byte (mcl2k2) clusters.
  > a certain vendor likes to make chips that specify the rx buffer
  > sizes in kilobyte increments. unfortunately it places the ethernet
  > header on the start of the rx buffer, which means if you give it a
  > mcl2k cluster, the ethernet header will not be ETHER_ALIGNed cos
  > mcl2k clusters are always allocated on 2k boundarys (cos they pack
  > into pages well). that in turn means the ip header wont be aligned
  > correctly.
  > the current workaround on these chips has been to let non-strict
  > alignment archs just use the normal 2k cluster, but use whatever
  > cluster can fit 2k + 2 on strict archs. that turns out to be the
  > 4k cluster, meaning we waste nearly 2k of space on every packet.
  > properly aligning the ethernet header and ip headers gives a
  > performance boost, even on non-strict archs. (dlg@)

  ~ uipc_mbuf.c                           

  > refactor m_pullup a bit.
  > the most important change is that if the requested data is already
  > in the first mbuf in the chain, return quickly.
  > if that isnt true, the code will try to use the first mbuf to fit
  > the requested data.
  > if that isnt true, it will prepend an mbuf, and maybe a cluster,
  > to fit the requested data.
  > m_pullup will now try to maintain the alignment of the original
  > payload, even when prepending a new mbuf for it.
  > ok mikeb@ (dlg@)

  ~ subr_percpu.c                         

  > use ncpusfound to size the percpu allocations.
  > ncpus is used on half the architectures to indicate the number of
  > cpus that have been hatched, and is used on them in things like ddb
  > to figure out how many cpus to shut down again.
  > ncpusfound is incremented during autoconf on MP machines to show
  > how big ncpus will probably become. percpu is initted after autoconf
  > but before cpus are hatched, so this works well. (dlg@)

  ~ kern_pledge.c                         

  > For consistency, allow symlinkat(2) in the same way as symlink(2);
  > no need to wait until the first program using it breaks...
  > "could make sense" semarie@ (and thanks for the cluestick)
  > OK deraadt@ (schwarze@)

net

  ~ if.h                                  

  > add a new pool for 2k + 2 byte (mcl2k2) clusters.
  > a certain vendor likes to make chips that specify the rx buffer
  > sizes in kilobyte increments. unfortunately it places the ethernet
  > header on the start of the rx buffer, which means if you give it a
  > mcl2k cluster, the ethernet header will not be ETHER_ALIGNed cos
  > mcl2k clusters are always allocated on 2k boundarys (cos they pack
  > into pages well). that in turn means the ip header wont be aligned
  > correctly.
  > the current workaround on these chips has been to let non-strict
  > alignment archs just use the normal 2k cluster, but use whatever
  > cluster can fit 2k + 2 on strict archs. that turns out to be the
  > 4k cluster, meaning we waste nearly 2k of space on every packet.
  > properly aligning the ethernet header and ip headers gives a
  > performance boost, even on non-strict archs. (dlg@)

  ~ switchofp.c                           

  > Avoid a use after free in swofp_flow_timeout().  The
  > swofp_flow_entry_delete() call frees the memory pointed to by the swfe
  > variable which was used later in the loop.
  > ok rzalamena@ (jsg@)

  ~ if_pfsync.c                           ~ pf.c
  ~ pfvar.h                               

  > Pass a struct pf_pdesc to pf_route() like it is done in the other
  > pf functions.  That means less parameters, more consistency and
  > later we can call functions that need a pd from pf_route().
  > OK sashan@ (bluhm@)

== usr.bin =========================================================== 04/05 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin

colrm

  ~ colrm.c                               

  > obvious case of s/LC_ALL/LC_CTYPE/, noticed by Jan Stary (schwarze@)

cvs

  ~ tag.c                                 

  > minor whitespace fixes. (joris@)

sndiod

  ~ dsp.c                                 ~ file.c
  ~ siofile.c                             ~ sock.c

  > Fix many typos in comments, from Michael W. Bombardieri <mb at ii.net>
  > (ratchov@)

== usr.sbin ========================================================== 05/05 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin

bgpd

  ~ rde.h                                 

  > Huawei squatted on BGP Path Attribute 30, and Cisco squatted on 31.  So,
  > IANA moved the Large Communities attribute to 32, which is a nice pun on
  > the problem it is solving. (phessler@)

config

  ~ ukcutil.c                             

  > Remove OLDSCSIBUS conditional. Unused since it was imported 21 years ago.
  > ok natano (tb@)

  ~ mkioconf.c                            

  > Remove some code that was already disabled when it was committed
  > 20 years ago.  While there, eliminate two dead assignments.
  > ok natano (tb@)

tcpdump

  ~ print-bgp.c                           

  > Huawei squatted on BGP Path Attribute 30, and Cisco squatted on 31.  So,
  > IANA moved the Large Communities attribute to 32, which is a nice pun on
  > the problem it is solving. (phessler@)

  ~ print-pfsync.c                        

  > Don't assume clr->ifname is a NUL-terminated printable string.
  > Use vis(3) to safely print ifname and stop at IFNAMSIZ bytes.
  > Found with afl by jsg@.  OK jsg@ (millert@)

===============================================================================
_______________________________________________
odc mailing list
[email protected]
http://www.squish.net/mailman/listinfo/odc

Reply via email to