OpenBSD src changes summary for 2016-04-07
==========================================

etc/examples/pkg.conf                   lib/libsndio
share/man                               sys/dev/pci
sys/kern                                sys/net
sys/ufs/ffs                             usr.bin/openssl
usr.sbin/vmd                            

== etc =============================================================== 01/06 ==

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

examples/pkg.conf

  ~ examples/pkg.conf                     

  > sync (sthen@)

== lib =============================================================== 02/06 ==

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

libsndio

  ~ sio_sun.c                             

  > Use the "new" audio(4) api and delete all the useless code to deal
  > with artificial complications caused by the old api. No behaviour
  > change.
  > ok armani, semarie (ratchov@)

== share ============================================================= 03/06 ==

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

man

  ~ man7/ports.7                          

  > update the ports link; from solene rapenne (jmc@)

  ~ man7/ports.7                          

  > Link to faq15.html#Ports instead of just faq15.html. This matches the
  > DESCRIPTION section that sthen@ fixed in November and reflects the
  > content of the former faq/ports/ports.html better.
  > discussed with jmc@ (tb@)

== sys =============================================================== 04/06 ==

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

dev/pci

  ~ drm/drm_linux.c                       

  > Return -ENOSPC if idr_alloc() fails to allocate an unused id instead of
  > spinning forever. (kettenis@)

  ~ drm/drm_crtc.c                        ~ drm/drm_crtc.h
  ~ drm/drmP.h                            

  > Retry the drm_crtc.c "idr"conversion.  Turns out the xf86-video-intel
  > driver
  > is buggy and trucates the ids to 8 bits.  So specifymaximum in the
  > idr_alloc()
  > call until that gets fixed. (kettenis@)

kern

  ~ vfs_subr.c                            

  > Share clone bitmap between aliased vnodes. This prevents duplicate clone
  > instance numbers being handed out for the same minor device.
  > ok mikeb (natano@)

net

  ~ pf.c                                  

  > Instead of panicking if an mbuf(9) already has a statekey dump its
  > content and unlink the statekey.
  > This should allow us to find the reminding corner cases of packets
  > looped back in the stack.
  > ok dlg@ (mpi@)

ufs/ffs

  ~ ffs_vnops.c                           

  > Always call bread_cluster() instead of calling it only if the current
  > logical block is contiguous to the previous one.
  > This logic is a left-over of the pre-bread_cluster() area.  When the
  > read-ahead version of bread(9) was used to prefetch blocks. Nowadays
  > bread_cluster() do the right thing (tm).
  > ok stefan@ (mpi@)

== usr.bin =========================================================== 05/06 ==

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

openssl

  ~ enc.c                                 

  > hexidecimal->hexadecimal; from mmcc
  > ok beck (jmc@)

== usr.sbin ========================================================== 06/06 ==

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

vmd

  ~ vmm.c                                 

  > Remove headers associated with code that's been moved to other .c files
  > ok mlarkin@ (guenther@)

  ~ loadfile_elf.c                        

  > Place a BOOTARG_END section at the end of the boot arguments list pushed
  > to the VM during boot. i386 guest kernels need this marker to boot, and
  > with this diff, it is possible to install and run an OpenBSD i386 guest
  > VM using vmm(4). Note that i386 guests require a host CPU that supports
  > unrestricted guest mode (eg, post-Nehalem) for the time being, hopefully
  > this can be addressed later. (mlarkin@)

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

Reply via email to