[odc] Daily src changes for 2007-10-13

ODC auto at squish.net
Sun Oct 14 07:00:01 BST 2007


OpenBSD src changes summary for 2007-10-13
==========================================

bin/chio                                distrib/sets
distrib/sgi                             etc/etc.sgi/disktab
regress/sbin                            regress/sys
sbin/ipsecctl                           sbin/nmeaattach
sbin/pfctl                              share/man
sys/arch/alpha/alpha                    sys/arch/amd64/amd64
sys/arch/arm/arm                        sys/arch/aviion/aviion
sys/arch/hp300/hp300                    sys/arch/i386/i386
sys/arch/luna88k/luna88k                sys/arch/m88k/include
sys/arch/m88k/m88k                      sys/arch/mac68k/mac68k
sys/arch/mips64/mips64                  sys/arch/mvme68k/mvme68k
sys/arch/mvme88k/mvme88k                sys/arch/powerpc/powerpc
sys/arch/sgi/localbus                   sys/arch/sparc/sparc
sys/arch/sparc64/sparc64                sys/arch/vax/vax
sys/dev/i2c                             sys/dev/ic
sys/dev/mii                             sys/dev/pci
sys/dev/usb                             sys/lib/libkern
sys/net                                 sys/nfs
usr.sbin/bgpd                           usr.sbin/dvmrpd
usr.sbin/hostapd                        usr.sbin/hoststated
usr.sbin/ifstated                       usr.sbin/ntpd
usr.sbin/ospf6ctl                       usr.sbin/ospf6d
usr.sbin/ospfd                          usr.sbin/ripd

== bin =============================================================== 01/08 ==

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

chio

  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

== distrib =========================================================== 02/08 ==

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

sets

  ~ lists/base/md.amd64                   ~ lists/base/md.sgi

  > sync (deraadt@)

sgi

  ~ Makefile                              

  > make obj in iso (deraadt@)

  ~ iso/Makefile                          

  > install to right place (deraadt@)

  ~ iso/Makefile                          

  > the iso can be smaller (deraadt@)

== etc =============================================================== 03/08 ==

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

etc.sgi/disktab

  ~ etc.sgi/disktab                       

  > the iso can be smaller (deraadt@)

== regress =========================================================== 04/08 ==

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

sbin

  ~ pfctl/Makefile                        + pfctl/pfail53.in
  + pfctl/pfail53.ok                      

  > we decided numbers used as strings is wrong (deraadt@)

sys

  ~ uvm/misc/misc.c                       

  > Do not attempt to work on more than SHMMAXPGS pages, makes this run
  > unmodified
  > on vax. (miod@)

== sbin ============================================================== 05/08 ==

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

ipsecctl

  ~ ipsecctl.c                            ~ ipsecctl.h
  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

nmeaattach

  ~ nmeaattach.c                          

  > Unconditionally call the TIOCSTSTAMP ioctl, this way calling nmeaattach(8)
  > without the '-t' option can be used to turn of tty timestamping.
  > problem noticed by sthen@, ok sthen, deraadt (mbalmer@)

pfctl

  ~ parse.y                               

  > support an include directive; file of course must also be "secure" like
  > the main configuration file; ok henning (deraadt@)

  ~ parse.y                               ~ pfctl.c
  ~ pfctl_parser.h                        

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

== share ============================================================= 06/08 ==

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

man

  ~ man5/pf.conf.5                        

  > support an include directive; file of course must also be "secure" like
  > the main configuration file; ok henning (deraadt@)

  ~ man4/acx.4                            ~ man4/bwi.4
  ~ man4/malo.4                           ~ man4/pgt.4

  > Bump firmware version;  Adapt to new package mechanism by rebuilding
  > those firmware packages.  Solves ``Warning: obsolete construct: @ignore''.
  > (mglocker@)

== sys =============================================================== 07/08 ==

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

arch/alpha/alpha

  ~ vm_machdep.c                          

  > Fix cpu_exit() comments to be more closer to reality. (miod@)

arch/amd64/amd64

  ~ vm_machdep.c                          

  > Fix cpu_exit() comments to be more closer to reality. (miod@)

  - Locore.c                              

  > Remove leftovers art forgot to prune... (miod@)

arch/arm/arm

  ~ vm_machdep.c                          

  > Fix cpu_exit() comments to be more closer to reality. (miod@)

  ~ cpuswitch.S                           

  > There is no need to fiddle with spl in cpu_idle_{enter,leave}, actually.
  > (miod@)

arch/aviion/aviion

  ~ machdep.c                             

  > Enable interrupts in secondary processors before invoking cpu_switchto(),
  > rather the expecting it to do this for us. (miod@)

arch/hp300/hp300

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

arch/i386/i386

  ~ vm_machdep.c                          

  > Fix cpu_exit() comments to be more closer to reality. (miod@)

arch/luna88k/luna88k

  ~ autoconf.c                            ~ machdep.c

  > Enable interrupts in secondary processors before invoking cpu_switchto(),
  > rather the expecting it to do this for us. (miod@)

arch/m88k/include

  ~ cpu.h                                 

  > It is no longer necessary to fiddle with spl in cpu_idle_{enter,leave} now
  > that proc_trampoline has been fixed. (miod@)

arch/m88k/m88k

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

  ~ eh_common.S                           

  > Be sure to spl0() in proc_trampoline, so that kernel threads start at
  > IPL_NONE. (miod@)

  ~ process.S                             

  > It is no longer necessary to fiddle with spl in cpu_idle_{enter,leave} now
  > that proc_trampoline has been fixed. (miod@)

arch/mac68k/mac68k

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

arch/mips64/mips64

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

  ~ context.S                             

  > There is no need to fiddle with spl in cpu_idle_{enter,leave}, actually.
  > (miod@)

arch/mvme68k/mvme68k

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

arch/mvme88k/mvme88k

  ~ autoconf.c                            ~ machdep.c

  > Enable interrupts in secondary processors before invoking cpu_switchto(),
  > rather the expecting it to do this for us. (miod@)

arch/powerpc/powerpc

  - Locore.c                              

  > Remove leftovers art forgot to prune... (miod@)

arch/sgi/localbus

  ~ macebus.c                             

  > Various typos in comments; Joel Sing (miod@)

arch/sparc/sparc

  - locore2.c                             

  > Remove leftovers art forgot to prune... (miod@)

arch/sparc64/sparc64

  ~ vm_machdep.c                          

  > Fix cpu_exit() comments to be more closer to reality. (miod@)

  - locore2.c                             

  > Remove leftovers art forgot to prune... (miod@)

arch/vax/vax

  ~ vm_machdep.c                          

  > Do not splhigh() before invoking sched_exit(), sched_exit() will do it
  > better. (miod@)

dev/i2c

  ~ spdmem.c                              

  > really correct : printing; ok deraadt@ (cnst@)

dev/ic

  ~ ar5xxx.c                              

  > add the AR5416 and AR5418 device IDs (needs some more testing) (reyk@)

  ~ fxp.c                                 ~ elink3.c
  ~ ath.c                                 

  > remove unneeded declarations that shadows existing vars; ok by many.
  > (fgsch@)

dev/mii

  ~ brgphy.c                              

  > Add support for BCM5906.
  > ok deraadt@ (kettenis@)

dev/pci

  ~ if_bge.c                              ~ if_bgereg.h

  > Add support for BCM5906.
  > ok deraadt@ (kettenis@)

  ~ if_skreg.h                            

  > Add Yukon-2 PHY powerdown bits. (kettenis@)

dev/usb

  ~ usbdevs                               

  > Add two Gude time signal station receivers. (mbalmer@)

  ~ usbdevs.h                             ~ usbdevs_data.h

  > sync. (mbalmer@)

lib/libkern

  ~ arch/hppa64/Makefile.inc              

  > Uncomment rule to build bcopy.S, and use that as our bcopy(9)
  > implementation. (kettenis@)

  ~ arch/hppa64/bcopy.m4                  

  > Make this actually work by using the right register numbers.  In the
  > conversion
  > from hppa the fact that t1-t4 actually number down from r22-r19 got somehow
  > lost. (kettenis@)

net

  ~ if_sl.c                               ~ if_fddisubr.c

  > remove unneeded declarations that shadows existing vars; ok by many.
  > (fgsch@)

nfs

  ~ nfs_socket.c                          ~ nfs_subs.c
  ~ nfs_var.h                             

  > Remove alot of dead kerberos code (add sane comments too).
  > Cleanup and partly redo the way we create the RPC header, by having
  > nfsm_rpchead() do a bit more work. Right now this is pretty RPCAUTH_UNIX
  > centric, but since it is the only auth method we support right now thats
  > fine.
  > Make sure we can never generate a zero xid, thats forbidden by the RFC.
  > Misc cleanup.
  > tested by a few. (thib@)

== usr.sbin ========================================================== 08/08 ==

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

bgpd

  ~ bgpd.h                                ~ config.c
  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

dvmrpd

  ~ dvmrpd.c                              ~ parse.y

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

hostapd

  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

hoststated

  ~ check_script.c                        

  > avoid errno trashing in signal handler (deraadt@)

  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

ifstated

  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

ntpd

  ~ parse.y                               

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

ospf6ctl

  - ospf6ctl.cat8                         

  > should not be in the tree (deraadt@)

ospf6d

  ~ ospf6d.8                              

  > superceed -> supersede; from Tamas TEVESZ (jmc@)

  ~ ospf6d.c                              ~ parse.y

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

  ~ control.c                             ~ ospfe.c
  ~ ospfe.h                               

  > From ospfd: Funny typo, it is fib not fip so adjust function name.
  > (claudio@)

ospfd

  ~ ospfd.8                               

  > superceed -> supersede; from Tamas TEVESZ (jmc@)

  ~ control.c                             ~ ospfe.c
  ~ ospfe.h                               

  > Funny typo, it is fib not fip so adjust function name. (claudio@)

  ~ ospfd.c                               ~ parse.y

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

ripd

  ~ parse.y                               ~ ripd.c

  > in all these programs using the same pfctl-derived parse.y, re-unify the
  > yylex implementation and the code which interacts with yylex.  this also
  > brings the future potential for include support to all of the parsers.
  > in the future please do not silly modifications to one of these files
  > without checking if you are de-unifying the code.
  > checked by developers in all these areas. (deraadt@)

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


More information about the odc mailing list