[odc] Daily src changes for 2007-06-05

ODC auto at squish.net
Wed Jun 6 07:00:01 BST 2007


OpenBSD src changes summary for 2007-06-05
==========================================

distrib/sets                            include/dirent.h
lib/libc                                lib/libpthread
lib/librthread                          regress/usr.bin
sbin/ifconfig                           share/man
sys/arch/alpha/alpha                    sys/arch/amd64/amd64
sys/arch/arm/arm                        sys/arch/aviion/aviion
sys/arch/hp300/dev                      sys/arch/hp300/hp300
sys/arch/hppa/hppa                      sys/arch/hppa64/hppa64
sys/arch/i386/i386                      sys/arch/landisk/landisk
sys/arch/luna88k/luna88k                sys/arch/mac68k/mac68k
sys/arch/macppc/dev                     sys/arch/macppc/macppc
sys/arch/mips64/mips64                  sys/arch/mvme68k/mvme68k
sys/arch/mvme88k/mvme88k                sys/arch/mvmeppc/mvmeppc
sys/arch/sparc/dev                      sys/arch/sparc/sparc
sys/arch/sparc64/dev                    sys/arch/sparc64/sparc64
sys/arch/vax/mba                        sys/arch/vax/mscp
sys/arch/vax/vax                        sys/arch/vax/vsa
sys/arch/zaurus/dev                     sys/compat/linux
sys/conf                                sys/dev
sys/dev/ata                             sys/dev/gpio
sys/dev/isa                             sys/dev/pci
sys/dev/raidframe                       sys/dev/usb
sys/isofs/cd9660                        sys/isofs/udf
sys/kern                                sys/scsi
sys/sys                                 sys/uvm
usr.bin/ssh                             usr.sbin/pkg_add
usr.sbin/sensorsd                       

== distrib =========================================================== 01/09 ==

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

sets

  ~ lists/base/md.alpha                   ~ lists/base/md.amd64
  ~ lists/base/md.armish                  ~ lists/base/md.cats
  ~ lists/base/md.hp300                   ~ lists/base/md.hppa
  ~ lists/base/md.hppa64                  ~ lists/base/md.i386
  ~ lists/base/md.mac68k                  ~ lists/base/md.macppc
  ~ lists/base/md.mvme68k                 ~ lists/base/md.mvmeppc
  ~ lists/base/md.sgi                     ~ lists/base/md.sparc
  ~ lists/base/md.sparc64                 ~ lists/base/md.zaurus

  > sync (deraadt@)

== include =========================================================== 02/09 ==

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

dirent.h

  ~ dirent.h                              

  > _FD_LOCK/UNLOCK() is libpthread specific and not needed for librthread, so
  > isolate its usage to libpthread only and replace with generic non-static
  > mutex support in the one place it is needed:
  > - remove _FD_LOCK/UNLOCK from lseek and ftruncate in libc and make the
  > functions weak so that libpthread can override with its own new
  > versions that do the locking.
  > - remove _thread_fd_lock/unlock() weak functions from libc and adjust
  > libpthread for the change.
  > - add generic _thread_mutex_lock/unlock/destroy() weak functions in libc
  > to support non-static mutexes in libc and add libpthread and librthread
  > implementations for them. libc can utilize non-static mutexes via the
  > new _MUTEX_LOCK/UNLOCK/DESTROY() macros. Actually these new macros can
  > support both static and non-static mutexes but currently only using
  > them for non-static.
  > - make opendir/closedir/readdir/readdir_r/seekdir/telldir() thread-safe
  > for both thread libraries by using a non-static mutex in the struct
  > _dirdesc (typedef DIR), utilizing it in the *dir functions and remove
  > remaining and incorrect _FD_LOCK/UNLOCK() use in libc.
  > - add comments to both thread libraries to indicate libc depends on the
  > current implementation of static mutex initialization. suggested by
  > marc@
  > - major bump libc and libpthread due to function removal, structure
  > change and weak symbol conversions.
  > okay marc@, tedu@ (kurt@)

== lib =============================================================== 03/09 ==

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

libc

  ~ sys/socket.2                          

  > one more IPX removal; ok henning (jmc@)

  - net/ipx.3                             - net/ipx_addr.c
  - net/ipx_ntoa.c                        ~ net/Makefile.inc

  > remove ipx-related stuff. objections nobody. major bump by kurt in a few
  > (henning@)

  ~ shlib_version                         ~ gen/closedir.c
  ~ gen/opendir.c                         ~ gen/readdir.c
  ~ gen/seekdir.c                         ~ gen/telldir.c
  ~ include/thread_private.h              ~ sys/ftruncate.c
  ~ sys/lseek.c                           ~ thread/Makefile.inc
  ~ thread/thread_fd.c                    + thread/unithread_mutex.c

  > _FD_LOCK/UNLOCK() is libpthread specific and not needed for librthread, so
  > isolate its usage to libpthread only and replace with generic non-static
  > mutex support in the one place it is needed:
  > - remove _FD_LOCK/UNLOCK from lseek and ftruncate in libc and make the
  > functions weak so that libpthread can override with its own new
  > versions that do the locking.
  > - remove _thread_fd_lock/unlock() weak functions from libc and adjust
  > libpthread for the change.
  > - add generic _thread_mutex_lock/unlock/destroy() weak functions in libc
  > to support non-static mutexes in libc and add libpthread and librthread
  > implementations for them. libc can utilize non-static mutexes via the
  > new _MUTEX_LOCK/UNLOCK/DESTROY() macros. Actually these new macros can
  > support both static and non-static mutexes but currently only using
  > them for non-static.
  > - make opendir/closedir/readdir/readdir_r/seekdir/telldir() thread-safe
  > for both thread libraries by using a non-static mutex in the struct
  > _dirdesc (typedef DIR), utilizing it in the *dir functions and remove
  > remaining and incorrect _FD_LOCK/UNLOCK() use in libc.
  > - add comments to both thread libraries to indicate libc depends on the
  > current implementation of static mutex initialization. suggested by
  > marc@
  > - major bump libc and libpthread due to function removal, structure
  > change and weak symbol conversions.
  > okay marc@, tedu@ (kurt@)

libpthread

  ~ thread/thread_tag.c                   

  > typos (kurt@)

  ~ shlib_version                         ~ thread/Makefile.inc
  ~ uthread/Makefile.inc                  ~ uthread/pthread_private.h
  ~ uthread/uthread_init.c                ~ uthread/uthread_mutex.c
  + thread/thread_mutex.c                 + uthread/uthread_ftruncate.c
  + uthread/uthread_lseek.c               

  > _FD_LOCK/UNLOCK() is libpthread specific and not needed for librthread, so
  > isolate its usage to libpthread only and replace with generic non-static
  > mutex support in the one place it is needed:
  > - remove _FD_LOCK/UNLOCK from lseek and ftruncate in libc and make the
  > functions weak so that libpthread can override with its own new
  > versions that do the locking.
  > - remove _thread_fd_lock/unlock() weak functions from libc and adjust
  > libpthread for the change.
  > - add generic _thread_mutex_lock/unlock/destroy() weak functions in libc
  > to support non-static mutexes in libc and add libpthread and librthread
  > implementations for them. libc can utilize non-static mutexes via the
  > new _MUTEX_LOCK/UNLOCK/DESTROY() macros. Actually these new macros can
  > support both static and non-static mutexes but currently only using
  > them for non-static.
  > - make opendir/closedir/readdir/readdir_r/seekdir/telldir() thread-safe
  > for both thread libraries by using a non-static mutex in the struct
  > _dirdesc (typedef DIR), utilizing it in the *dir functions and remove
  > remaining and incorrect _FD_LOCK/UNLOCK() use in libc.
  > - add comments to both thread libraries to indicate libc depends on the
  > current implementation of static mutex initialization. suggested by
  > marc@
  > - major bump libc and libpthread due to function removal, structure
  > change and weak symbol conversions.
  > okay marc@, tedu@ (kurt@)

librthread

  ~ rthread_libc.c                        ~ rthread_sync.c

  > _FD_LOCK/UNLOCK() is libpthread specific and not needed for librthread, so
  > isolate its usage to libpthread only and replace with generic non-static
  > mutex support in the one place it is needed:
  > - remove _FD_LOCK/UNLOCK from lseek and ftruncate in libc and make the
  > functions weak so that libpthread can override with its own new
  > versions that do the locking.
  > - remove _thread_fd_lock/unlock() weak functions from libc and adjust
  > libpthread for the change.
  > - add generic _thread_mutex_lock/unlock/destroy() weak functions in libc
  > to support non-static mutexes in libc and add libpthread and librthread
  > implementations for them. libc can utilize non-static mutexes via the
  > new _MUTEX_LOCK/UNLOCK/DESTROY() macros. Actually these new macros can
  > support both static and non-static mutexes but currently only using
  > them for non-static.
  > - make opendir/closedir/readdir/readdir_r/seekdir/telldir() thread-safe
  > for both thread libraries by using a non-static mutex in the struct
  > _dirdesc (typedef DIR), utilizing it in the *dir functions and remove
  > remaining and incorrect _FD_LOCK/UNLOCK() use in libc.
  > - add comments to both thread libraries to indicate libc depends on the
  > current implementation of static mutex initialization. suggested by
  > marc@
  > - major bump libc and libpthread due to function removal, structure
  > change and weak symbol conversions.
  > okay marc@, tedu@ (kurt@)

== regress =========================================================== 04/09 ==

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

usr.bin

  + cvs/Makefile                          + cvs/import_seed/seed1.txt

  > add very basic regress framework for opencvs.
  > more to come.
  > ok joris@ (niallo@)

  ~ cvs/Makefile                          

  > Wrap long lines. (xsa@)

== sbin ============================================================== 05/09 ==

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

ifconfig

  ~ ifconfig.c                            

  > remove support for ipx. okay claudio@ (kurt@)

== share ============================================================= 06/09 ==

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

man

  ~ man4/wpi.4                            

  > Major wpi(4) update:
  > 1/ Update the driver to use the new firmware images from Intel (2.14.3.)
  > 2/ Read the list of supported channels from the EEPROM instead of having
  > it hard-coded in the driver.
  > 3/ Limit output power to what is specified in EEPROM.
  > 4/ Decrease output power for highest OFDM rates to reduce distortion.
  > 5/ Automatically adjust output power to temperature changes for increased
  > throughput and range.
  > 6/ Attach the adapter's onboard thermal sensor to the sensor framework.
  > 7/ Replace 'magic' fields in structures with their correct definitions.
  > NOTE1: you must upgrade your wpi-firmware package to rev 2.14.3 or the
  > driver will stop working.
  > NOTE2: if you are using a channel not allowed by the regulatory domain
  > of your adapter, you will no longer be able to associate. (damien@)

== sys =============================================================== 07/09 ==

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

arch/alpha/alpha

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/amd64/amd64

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/arm/arm

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/aviion/aviion

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/hp300/dev

  ~ hd.c                                  

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/hp300/hp300

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/hppa/hppa

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ vm_machdep.c                          

  > Use phys_map, not kernel_map in v{,un}mapbuf. ok mickey (miod@)

arch/hppa64/hppa64

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ vm_machdep.c                          

  > Use phys_map, not kernel_map in v{,un}mapbuf. ok mickey (miod@)

arch/i386/i386

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/landisk/landisk

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/luna88k/luna88k

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/mac68k/mac68k

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/macppc/dev

  ~ tpms.c                                

  > Remove the "Static" function declaration.  It is defined to be
  > empty and confuses the source code reader.	As discussed with dlg and jsg.
  > (mbalmer@)

  ~ tpms.c                                

  > Remove the comment "Static function protoypes".  Static is gone in USB.
  > no binary change. (mbalmer@)

arch/macppc/macppc

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/mips64/mips64

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/mvme68k/mvme68k

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/mvme88k/mvme88k

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/mvmeppc/mvmeppc

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/sparc/dev

  ~ fd.c                                  ~ presto.c
  ~ xd.c                                  ~ xy.c

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/sparc/sparc

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/sparc64/dev

  ~ fd.c                                  

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/sparc64/sparc64

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/vax/mba

  ~ hp.c                                  

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/vax/mscp

  ~ mscp_disk.c                           

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/vax/vax

  ~ disksubr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ disksubr.c                            

  > bounds_check_with_label() checks for i/o outside of the partition and
  > for overwriting the disklabel. Reorder some checks so all copies of
  > bounds_check_with_label do the checks in the same order. Order picked
  > by using the currently most popular one. Should be no functional
  > change.
  > "If it's boring, commit it" deraadt@ (krw@)

arch/vax/vsa

  ~ hdc9224.c                             

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

arch/zaurus/dev

  ~ zaurus_flash.c                        

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

compat/linux

  ~ linux_blkio.c                         ~ linux_hdio.c

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

conf

  ~ GENERIC                               ~ files

  > IPX is about to go away, remove commented out IPX options in GENERIC and
  > ipx related files (doesn't compile anyway) (henning@)

dev

  ~ ccd.c                                 ~ flash.c
  ~ ramdisk.c                             ~ softraid.c
  ~ vnd.c                                 

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ softraid.c                            

  > consistently use one variable instead of deriving it repeatedly
  > from and ok marco@ (todd@)

  ~ softraid.c                            

  > Shuffle calculation of physical block so that bounds checking is not off by
  > 48 blocks (metadata + metdata offset).  Found by drahn.
  > Fix panic message while in the same area.
  > Help from otto who wrote a diff that worked around the issue.
  > ok deraadt (marco@)

dev/ata

  ~ wd.c                                  

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

dev/gpio

  ~ gpioiic.c                             

  > Switch to rwlock(9)
  > ok grange@ (jsg@)

dev/isa

  ~ fd.c                                  ~ mcd.c

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

  ~ gscsio.c                              

  > Switch to rwlock(9)
  > ok grange@ (jsg@)

dev/pci

  ~ if_wpi.c                              ~ if_wpireg.h
  ~ if_wpivar.h                           

  > Major wpi(4) update:
  > 1/ Update the driver to use the new firmware images from Intel (2.14.3.)
  > 2/ Read the list of supported channels from the EEPROM instead of having
  > it hard-coded in the driver.
  > 3/ Limit output power to what is specified in EEPROM.
  > 4/ Decrease output power for highest OFDM rates to reduce distortion.
  > 5/ Automatically adjust output power to temperature changes for increased
  > throughput and range.
  > 6/ Attach the adapter's onboard thermal sensor to the sensor framework.
  > 7/ Replace 'magic' fields in structures with their correct definitions.
  > NOTE1: you must upgrade your wpi-firmware package to rev 2.14.3 or the
  > driver will stop working.
  > NOTE2: if you are using a channel not allowed by the regulatory domain
  > of your adapter, you will no longer be able to associate. (damien@)

dev/raidframe

  ~ rf_copyback.c                         ~ rf_disks.c
  ~ rf_openbsdkintf.c                     ~ rf_reconstruct.c

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

dev/usb

  ~ ehci.c                                ~ hid.c
  ~ if_aue.c                              ~ if_axe.c
  ~ if_cdce.c                             ~ if_cue.c
  ~ if_kue.c                              ~ if_ral.c
  ~ if_rum.c                              ~ if_uath.c
  ~ if_udav.c                             ~ if_upl.c
  ~ if_url.c                              ~ moscom.c
  ~ ohci.c                                ~ uark.c
  ~ uaudio.c                              ~ uberry.c
  ~ ubsa.c                                ~ ucom.c
  ~ ucycom.c                              ~ udsbr.c
  ~ ueagle.c                              ~ uftdi.c
  ~ ugen.c                                ~ uhci.c
  ~ uhid.c                                ~ uhidev.c
  ~ uhub.c                                ~ uipaq.c
  ~ ukbd.c                                ~ umass.c
  ~ umass_quirks.c                        ~ umct.c
  ~ umodem.c                              ~ ums.c
  ~ uow.c                                 ~ uplcom.c
  ~ usb.c                                 ~ usb_mem.c
  ~ usb_port.h                            ~ usb_quirks.c
  ~ usb_subr.c                            ~ usbdi.c
  ~ usbdi_util.c                          ~ uscanner.c
  ~ uslcom.c                              ~ usscanner.c
  ~ uts.c                                 ~ uvisor.c
  ~ uvscom.c                              

  > Remove the "Static" declaration of many functions.	It was defined to be
  > empty
  > and it was not consistently used.  It was confusing as it suggested these
  > functions were static, which they were not.
  > discussed with dlg and jsg, ok jsg. (mbalmer@)

isofs/cd9660

  ~ cd9660_vfsops.c                       

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

isofs/udf

  ~ udf_subr.c                            

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

kern

  ~ subr_disk.c                           

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

scsi

  ~ cd.c                                  ~ sd.c

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

sys

  ~ disklabel.h                           

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

uvm

  ~ uvm_vnode.c                           

  > use six new macros to access & store the 48-bit disklabel fields related
  > to size.  tested on almost all machines, double checked by miod and krw
  > next comes the type handling surrounding these values (deraadt@)

== usr.bin =========================================================== 08/09 ==

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

ssh

  ~ kex.c                                 ~ kex.h
  ~ mac.c                                 ~ mac.h
  ~ monitor_wrap.c                        ~ packet.c

  > Preserve MAC ctx between packets, saving 2xhash calls per-packet.
  > Yields around a 12-16% end-to-end speedup for arcfour256/hmac-md5
  > patch from markus@ tested dtucker@ and myself, ok markus@ and me (I'm
  > committing at his request) (djm@)

== usr.sbin ========================================================== 09/09 ==

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

pkg_add

  ~ OpenBSD/Replace.pm                    

  > reuse the compute_closure code. (espie@)

  ~ pkg_add                               ~ OpenBSD/Dependencies.pm
  ~ OpenBSD/Vstat.pm                      

  > allow accessing all older values (make a semantic distinction), so that
  > adjust_dependencies gets access to all. This fixes some bogus replacements.
  > (espie@)

sensorsd

  ~ sensorsd.conf.5                       

  > various grammar/text improvements; (jmc@)

===============================================================================


More information about the odc mailing list