OpenBSD src changes summary for 2016-03-18
==========================================

bin/csh                                 share/man
sys/arch/arm/arm                        sys/arch/arm/conf
sys/arch/arm/include                    sys/arch/octeon/conf
sys/arch/octeon/dev                     sys/net
sys/scsi                                usr.bin/mandoc
usr.bin/tmux                            usr.sbin/pkg_add

== bin =============================================================== 01/05 ==

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

csh

  ~ csh.c                                 

  > Replace ioctl(fd, FIOCLEX) with fcntl(fd, F_SETFD, FD_CLOEXEC)
  > No functional change.  "I like the idea" from guenther@ (millert@)

== share ============================================================= 02/05 ==

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

man

  ~ man4/ipsec.4                          

  > +.Xr ipsec.conf 5 ,
  > from rob pierce (jmc@)

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

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

arch/arm/arm

  ~ cpu.c                                 ~ cpufunc.c
  ~ pmap.c                                

  > Remove support for ARM8, an old armv4 processor without thumb that was
  > never supported by any arm port and wouldn't have built due to a missing
  > cpufunc_asm_arm8.S file.
  > From Patrick Wildt. (jsg@)

  - cpufunc_asm_arm9.S                    ~ cpu.c
  ~ cpufunc.c                             ~ pmap.c

  > Remove support for ARM9T (armv4t).  Not used by any of the arm platforms.
  > From Patrick Wildt. (jsg@)

arch/arm/conf

  ~ files.arm                             

  > Remove support for ARM8, an old armv4 processor without thumb that was
  > never supported by any arm port and wouldn't have built due to a missing
  > cpufunc_asm_arm8.S file.
  > From Patrick Wildt. (jsg@)

  ~ files.arm                             

  > Remove support for ARM9T (armv4t).  Not used by any of the arm platforms.
  > From Patrick Wildt. (jsg@)

arch/arm/include

  ~ armreg.h                              ~ cpuconf.h
  ~ cpufunc.h                             ~ pmap.h

  > Remove support for ARM8, an old armv4 processor without thumb that was
  > never supported by any arm port and wouldn't have built due to a missing
  > cpufunc_asm_arm8.S file.
  > From Patrick Wildt. (jsg@)

  ~ armreg.h                              ~ cpuconf.h
  ~ cpufunc.h                             ~ pmap.h

  > Remove support for ARM9T (armv4t).  Not used by any of the arm platforms.
  > From Patrick Wildt. (jsg@)

  ~ cpuconf.h                             

  > IXP425 is v5 not v4.  Same change by msaitoh in NetBSD rev 1.16. (jsg@)

arch/octeon/conf

  ~ GENERIC                               ~ RAMDISK
  ~ files.octeon                          

  > add octuctl, a driver for the Octeon II usb controller interface, and
  > attachments for ehci and ohci.
  > ok uebayasi@ jasper@ visa@ mpi@ (jmatthew@)

arch/octeon/dev

  ~ octeon_iobus.c                        + octehci.c
  + octohci.c                             + octuctl.c
  + octuctlreg.h                          + octuctlvar.h

  > add octuctl, a driver for the Octeon II usb controller interface, and
  > attachments for ehci and ohci.
  > ok uebayasi@ jasper@ visa@ mpi@ (jmatthew@)

net

  ~ if_vlan.c                             

  > refactor the vlan multicast list handling.
  > the previous code had vlan_ether_purgemulti and vlan_ether_resetmulti,
  > both of which did too many things. purgemulti would try and remove
  > the multicast entries from the parent, and then free the local
  > copies of the addresses. resetmulti would try to remove the address
  > from the parent, and then optionally try to add them to a new parent.
  > resetmulti in particular makes the overall vlan config steps fairly
  > twisty.
  > the refactor offers vlan_multi_apply, and vlan_multi_free. multi_apply
  > simply adds or removes the multicast addresses from a parent
  > interface. it is now up to the config steps to call them appropriately
  > when configuring a parent or a new parent. vlan_multi_free only
  > deletes the memory associated with the vlans multicast addresses.
  > vlan_multi_apply is called when a parent is configured (ie, ifconfig
  > vlan0 up), or unconfigured (ifconfig vlan0 down or a detach of the
  > parent). vlan_multi_free is called when a vlan interface is destroyed
  > (ifconfig vlan0 destroy).
  > ok mpi@ (dlg@)

scsi

  ~ sd.c                                  

  > After sleeping and before accessing sc_link, check that scsi disk
  > is not dying.
  > OK krw@ (bluhm@)

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

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

mandoc

  ~ man.cgi.8                             

  > document short URIs (schwarze@)

  ~ cgi.c                                 ~ cgi.h.example
  ~ man.cgi.8                             

  > Make the SCRIPT_NAME logic simpler, safer, and make it actually work;
  > in part based on ideas by bentley@.
  > While here, improve the documentation. (schwarze@)

  ~ man.cgi.8                             

  > double word; (jmc@)

tmux

  ~ key-string.c                          ~ mode-key.c
  ~ server-client.c                       ~ tmux.1
  ~ tmux.h                                

  > Instead of reusing MouseUp at the finish of a drag, add a new key
  > MouseDragEnd. It can be useful to bind them separately in copy mode.
  > (nicm@)

  ~ window-copy.c                         

  > Make scrolling behaviour more sensible and maintain cursor position, as
  > if the same had been done line-by-line. From Michal Mazurek. (nicm@)

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

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

pkg_add

  ~ OpenBSD/PackageRepository.pm          

  > use properly separated _pkgfetch user.
  > abort if you can't find it. if you somehow managed NOT to update your
  > users thru sysmerge or the normal build process, you deserve this. (espie@)

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

Reply via email to