[odc] Daily src changes for 2008-04-09

[ODC]

OpenBSD src changes summary for 2008-04-09
==========================================

libexec/ld.so                           share/man
sys/arch/alpha/alpha                    sys/arch/amd64/amd64
sys/arch/aviion/aviion                  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/macppc                  sys/arch/mvme68k/mvme68k
sys/arch/mvme88k/mvme88k                sys/arch/mvmeppc/mvmeppc
sys/arch/sgi/sgi                        sys/arch/solbourne/solbourne
sys/arch/sparc/sparc                    sys/arch/sparc64/sparc64
sys/arch/vax/vax                        sys/conf
sys/dev                                 sys/dev/i2c
sys/dev/ic                              sys/dev/pci
sys/dev/usb                             sys/sys
sys/uvm                                 

== libexec =========================================================== 01/03 ==

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

ld.so

  ~ dl_prebind.c                          ~ dlfcn.c
  ~ library.c                             ~ resolve.c
  ~ resolve.h                             ~ alpha/rtld_machine.c
  ~ amd64/rtld_machine.c                  ~ arm/rtld_machine.c
  ~ hppa/archdep.h                        ~ hppa/rtld_machine.c
  ~ i386/rtld_machine.c                   ~ ldconfig/dl_prebind.c
  ~ ldconfig/prebind.c                    ~ mips64/rtld_machine.c
  ~ powerpc/rtld_machine.c                ~ sh/rtld_machine.c
  ~ sparc/rtld_machine.c                  ~ sparc64/rtld_machine.c

  > Improve support for shared libs linked at non-zero addreses:
  > - rename private values in struct elf_object to better
  > describe their meaning:
  > s/load_offs/obj_base/ "object's address '0' base"
  > s/load_addr/load_base/ "The base address of the loadable
  > segments"
  > - gdb needs the obj_base value so swap positions with load_base in
  > struct elf_object
  > - fix a few occurrences of where load_base was used instead of
  > obj_base.
  > With help and okay drahn@ (kurt@)

== share ============================================================= 02/03 ==

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

man

  ~ man4/sdtemp.4                         

  > Recognize and support the Microchip MCP9805 JC-42.2 sensor (we hope; I am
  > simply going through datasheets found on the net...) (deraadt@)

  ~ man4/sdtemp.4                         

  > support the NPX SE97 too (deraadt@)

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

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

arch/alpha/alpha

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/amd64/amd64

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/aviion/aviion

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/hp300/hp300

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/hppa/hppa

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/hppa64/hppa64

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/i386/i386

  ~ trap.c                                

  > Don't grab the kernel biglock for syscalls marked SY_NOLOCK;
  > matches what amd64 and sparc64 do.
  > tested by johan@ and laurent@
  > ok toby@,dlg@ (thib@)

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/landisk/landisk

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/luna88k/luna88k

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/mac68k/mac68k

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/macppc/macppc

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/mvme68k/mvme68k

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/mvme88k/mvme88k

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/mvmeppc/mvmeppc

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/sgi/sgi

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/solbourne/solbourne

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/sparc/sparc

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/sparc64/sparc64

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

arch/vax/vax

  ~ machdep.c                             

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

conf

  ~ files                                 

  > Initial import for uvideo(4) and video(4):
  > uvideo(4) is a driver for USB video device class devices including webcams,
  > camcorders and other cameras.
  > video(4) is a device-independent layer that implements the V4L2 (Video for
  > Linux Two)
  > API.
  > These drivers are *really* work in progress so don't even try to use them
  > just yet,
  > because the driver still has some issues, even if it can be used to capture
  > simple
  > MJPEG videos.
  > ok mglocker@, deraadt@ (robert@)

dev

  + video.c                               + video_if.h
  + videovar.h                            

  > Initial import for uvideo(4) and video(4):
  > uvideo(4) is a driver for USB video device class devices including webcams,
  > camcorders and other cameras.
  > video(4) is a device-independent layer that implements the V4L2 (Video for
  > Linux Two)
  > API.
  > These drivers are *really* work in progress so don't even try to use them
  > just yet,
  > because the driver still has some issues, even if it can be used to capture
  > simple
  > MJPEG videos.
  > ok mglocker@, deraadt@ (robert@)

dev/i2c

  ~ sdtemp.c                              ~ i2c_scan.c

  > Recognize and support the Microchip MCP9805 JC-42.2 sensor (we hope; I am
  > simply going through datasheets found on the net...) (deraadt@)

  ~ i2c_scan.c                            ~ sdtemp.c

  > support the NPX SE97 too (deraadt@)

dev/ic

  ~ com.c                                 

  > Increase buffer size sent to the fifo, and clamp the size correctly.
  > Scrub the buffer afterwards, too (deraadt@)

dev/pci

  ~ if_em.c                               

  > dma sync the tx ring and post new packets to the chip once per call to
  > the start routine instead of once per packet.
  > tested on various archs including amd64, i386, and sparc64. (dlg@)

  ~ agp.c                                 

  > device_lookup() increments the reference count for the device, and we
  > never decrement it. Since kernel mappings aren't touched if the device
  > is closed, just grab the softc manually instead on these functions, this
  > means close will be called after the kernel api has been used.
  > ok kettenis at . (oga@)

  ~ ehci_pci.c                            

  > from freebsd; tested in snaps for weeks
  > date: 2008/03/12 20:57:17;	author: jhb;  state: Exp;  lines: +4 -1
  > Relax the BIOS/OS sempahore handoff code to workaround different hard
  > hangs (one at boot, one at shutdown) in recent machines.  First, only try
  > to take ownership of the EHCI controller if the BIOS currently owns the
  > controller.  On a HP DL160 G5, the machine hangs when we try to take
  > ownership.	Second, don't bother trying to give up ownership of the
  > controller during shutdown.  It's not strictly required and a Dell DCS S29
  > hangs on shutdown after the config write.
  > Both of these changes match the behavior of the Linux EHCI driver.	I also
  > think both of these hangs are caused by bugs in the BIOS' SMM handler
  > causing it to get stuck in an infinite loop in SMM. (deraadt@)

  ~ pci_map.c                             

  > On sparc64, a zero base address doesn't mean the BAR is invalid.  We
  > probably
  > need a MD base address validation function, but skipping the check on
  > sparc64
  > will do for now.
  > ok deraadt@ (kettenis@)

dev/usb

  ~ files.usb                             + uvideo.c
  + uvideo.h                              

  > Initial import for uvideo(4) and video(4):
  > uvideo(4) is a driver for USB video device class devices including webcams,
  > camcorders and other cameras.
  > video(4) is a device-independent layer that implements the V4L2 (Video for
  > Linux Two)
  > API.
  > These drivers are *really* work in progress so don't even try to use them
  > just yet,
  > because the driver still has some issues, even if it can be used to capture
  > simple
  > MJPEG videos.
  > ok mglocker@, deraadt@ (robert@)

  ~ uvideo.c                              ~ uvideo.h

  > Add OpenBSD cvs id. (mglocker@)

sys

  ~ conf.h                                + videoio.h

  > Initial import for uvideo(4) and video(4):
  > uvideo(4) is a driver for USB video device class devices including webcams,
  > camcorders and other cameras.
  > video(4) is a device-independent layer that implements the V4L2 (Video for
  > Linux Two)
  > API.
  > These drivers are *really* work in progress so don't even try to use them
  > just yet,
  > because the driver still has some issues, even if it can be used to capture
  > simple
  > MJPEG videos.
  > ok mglocker@, deraadt@ (robert@)

uvm

  ~ uvm_extern.h                          ~ uvm_page.c

  > Add new stub uvm_shutdown() and call it from the right place in MD boot()
  > (deraadt@)

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