OpenBSD src changes summary for 2015-11-25 ==========================================
distrib/sets games/atc games/battlestar games/canfield games/snake games/tetris lib/libc lib/libsndio libexec/talkd sbin/disklabel sbin/fdisk sbin/fsck_ext2fs sbin/ifconfig sbin/newfs share/man sys/arch/armv7/imx sys/arch/armv7/omap sys/arch/armv7/sunxi sys/arch/macppc/dev sys/arch/octeon/dev sys/arch/sgi/dev sys/arch/sgi/hpc sys/arch/socppc/dev sys/arch/sparc/dev sys/arch/sparc64/dev sys/arch/sparc64/sparc64 sys/arch/vax/if sys/dev/ic sys/dev/isa sys/dev/pci sys/dev/pcmcia sys/dev/sbus sys/dev/usb sys/kern sys/net sys/net80211 usr.bin/sndiod usr.bin/tmux usr.sbin/vmd == distrib =========================================================== 01/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib sets ~ lists/comp/mi > sync (deraadt@) ~ lists/comp/mi > sync (deraadt@) == games ============================================================= 02/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games atc ~ Makefile > Remove operations that "touch" scorefiles at install time. (deraadt@) battlestar ~ Makefile > Remove operations that "touch" scorefiles at install time. (deraadt@) canfield ~ canfield/canfield.c > Remove now unused gid_t variable. > From Ricardo Mestre. Thanks! > go for it! deraadt@ (tb@) snake ~ Makefile > Remove operations that "touch" scorefiles at install time. (deraadt@) tetris ~ tetris.6 > The scorefile is hidden. > From Ricardo Mestre, thanks! (tb@) == lib =============================================================== 03/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib libc ~ gen/syslog_r.c ~ hidden/syslog.h ~ sys/Makefile.inc > Add a syscall stub for sendsyslog2(2), and use it in syslog_r(3), passing > LOG_CONS to the kernel. As a result, the /dev/console opening code can > be removed. > ok kettenis millert beck (deraadt@) ~ sys/stack_protector.c > Rather than using syslog(3) (which pulls in snprintf), creating the report > string using simpler strings functions and use sendsyslog2() directly. > Also, use the LOG_CONS flag so that single-user reports are more clear. > Use a buffer size of 1024 (from bluhm) > discussed with guenther and matthew > ok millert (deraadt@) ~ net/ruserok.c > syslog() here is pointless; ok millert (deraadt@) ~ Makefile.inc > Make using a deprecated function an error instead of just a warning > ok millert@ kettenis@ (guenther@) ~ stdlib/icdb.c + hidden/icdb.h > Wrap <icdb.h> so that calls go direct and the symbols are all weak > ok tedu@ (guenther@) ~ gen/pwcache.c > group_from_gid: use _GR_BUF_LEN instead of _PW_BUF_LEN (jcs@) libsndio ~ sndio.7 > -M option was removed, midi ports registered with -q (ratchov@) == libexec =========================================================== 04/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/libexec talkd ~ talkd.8 > rename internally to ntalkd, after the binary; this way both > "man talkd" and "man ntalkd" work; > issue reported by sobrado; fix from schwarze (jmc@) == sbin ============================================================== 05/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin disklabel ~ disklabel.c > -A needs cflag too. Noted by sthen@ during install. (krw@) fdisk ~ cmd.c > Try harder to prevent 0-length partitions from being defined. > Suggested by & ok tim@ (krw@) fsck_ext2fs ~ main.c > Do not do the early pledge, because hotroot() is a lie. fsck_extfs > is not correct duid-aware by itself. (deraadt@) ifconfig ~ ifconfig.c > Put back 1.305 without breaking the hand rolled inet_net_pton(3) case > for IPv4. > Tested by sebastia@ and krw@ (mpi@) newfs ~ newfs.c > We can't make a pledge if we're mount_mfs(8) as we need the ability to call > mount(2). > ok deraadt@ (kettenis@) == share ============================================================= 06/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share man ~ man9/Makefile ~ man9/ifq_enqueue.9 > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ man9/Makefile ~ man9/uvm.9 > add uvm_uarea_{alloc,free} to NAME and MLINKS; > found by schwarze; > ok schwarze guenther (jmc@) == sys =============================================================== 07/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys arch/armv7/imx ~ imxenet.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/armv7/omap ~ if_cpsw.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ if_cpsw.c > Small fixes related to the IFF_OACTIVE removal. (mpi@) arch/armv7/sunxi ~ sxie.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/macppc/dev ~ if_bm.c ~ if_mc.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/octeon/dev ~ if_cnmac.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ if_cnmac.c > Simplify the setup of gather segments. (visa@) arch/sgi/dev ~ if_iec.c ~ if_mec.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/sgi/hpc ~ if_sq.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/socppc/dev ~ if_tsec.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/sparc/dev ~ be.c ~ hme.c ~ if_ie.c ~ qe.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ be.c ~ hme.c ~ if_ie.c ~ qe.c ~ qec.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) arch/sparc64/dev ~ vnet.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) arch/sparc64/sparc64 ~ pmap.c > Don't bother keeping track of the resident count for the kernel pmap. > (kettenis@) arch/vax/if ~ if_de.c ~ if_qe.c ~ sgec.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) dev/ic ~ acx.c ~ aic6915.c ~ am7990.c ~ am79900.c ~ an.c ~ ar5008.c ~ ar9003.c ~ ath.c ~ athn.c ~ atw.c ~ bwi.c ~ dc.c ~ dp8390.c ~ elink3.c ~ fxp.c ~ gem.c ~ hme.c ~ i82596.c ~ if_wi.c ~ lance.c ~ lemac.c ~ malo.c ~ mtd8xx.c ~ pgt.c ~ re.c ~ rt2560.c ~ rt2661.c ~ rt2860.c ~ rtl81x9.c ~ rtw.c ~ smc83c170.c ~ smc91cxx.c ~ ti.c ~ xl.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ dcreg.h > trim unused variable (dlg@) ~ i82596.c > Small fixes related to the IFF_OACTIVE removal. (mpi@) ~ elink3.c ~ lemac.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) dev/isa ~ if_ef_isapnp.c ~ if_eg.c ~ if_el.c ~ if_ex.c ~ if_ie.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ fd.c ~ spkr.c > add size to free (tedu@) ~ if_ef_isapnp.c ~ if_eg.c ~ if_ep_isa.c ~ if_ie.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) dev/pci ~ if_age.c ~ if_alc.c ~ if_ale.c ~ if_bce.c ~ if_bge.c ~ if_bnx.c ~ if_cas.c ~ if_de.c ~ if_em.c ~ if_et.c ~ if_ipw.c ~ if_iwi.c ~ if_iwm.c ~ if_iwn.c ~ if_ix.c ~ if_ixgb.c ~ if_jme.c ~ if_lge.c ~ if_lii.c ~ if_msk.c ~ if_myx.c ~ if_nep.c ~ if_nfe.c ~ if_nge.c ~ if_nxe.c ~ if_oce.c ~ if_pcn.c ~ if_rtwn.c ~ if_se.c ~ if_sis.c ~ if_sk.c ~ if_ste.c ~ if_stge.c ~ if_tht.c ~ if_tl.c ~ if_txp.c ~ if_vge.c ~ if_vic.c ~ if_vio.c ~ if_vmx.c ~ if_vr.c ~ if_vte.c ~ if_wb.c ~ if_wpi.c ~ if_xge.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ if_de.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) dev/pcmcia ~ if_malo.c ~ if_xe.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ if_ep_pcmcia.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) dev/sbus ~ be.c ~ qe.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ be.c ~ qe.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) dev/usb ~ if_athn_usb.c ~ if_atu.c ~ if_aue.c ~ if_axe.c ~ if_axen.c ~ if_cdce.c ~ if_cdcef.c ~ if_cue.c ~ if_kue.c ~ if_mos.c ~ if_otus.c ~ if_ral.c ~ if_rsu.c ~ if_rum.c ~ if_run.c ~ if_smsc.c ~ if_uath.c ~ if_udav.c ~ if_ugl.c ~ if_upgt.c ~ if_upl.c ~ if_url.c ~ if_urndis.c ~ if_urtw.c ~ if_urtwn.c ~ if_zyd.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) ~ if_ugl.c ~ if_upl.c > Network drivers should not include <net/route.h> or <net/netisr.h> (mpi@) kern ~ kern_pledge.c > permit kern.maxpartitions (deraadt@) net ~ if.c ~ if_var.h > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) net80211 ~ ieee80211_pae_output.c > replace IFF_OACTIVE manipulation with mpsafe operations. > there are two things shared between the network stack and drivers > in the send path: the send queue and the IFF_OACTIVE flag. the send > queue is now protected by a mutex. this diff makes the oactive > functionality mpsafe too. > IFF_OACTIVE is part of if_flags. there are two problems with that. > firstly, if_flags is a short and we dont have any MI atomic operations > to manipulate a short. secondly, while we could make the IFF_OACTIVE > operates mpsafe, all changes to other flags would have to be made > safe at the same time, otherwise a read-modify-write cycle on their > updates could clobber the oactive change. > instead, this moves the oactive mark into struct ifqueue and provides > an API for changing it. there's ifq_set_oactive, ifq_clr_oactive, > and ifq_is_oactive. these are modelled on ifsq_set_oactive, > ifsq_clr_oactive, and ifsq_is_oactive in dragonflybsd. > this diff includes changes to all the drivers manipulating IFF_OACTIVE > to now use the ifsq_{set,clr_is}_oactive API too. > ok kettenis@ mpi@ jmatthew@ deraadt@ (dlg@) == usr.bin =========================================================== 08/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin sndiod ~ sock.h > spacing (ratchov@) ~ dev.c ~ midi.c > Allocate device names in the heap, so they can be generated. (ratchov@) ~ dev.c > fix latest: don't set d->path as we just allocated it (ratchov@) tmux ~ client.c > Don't print error if none to print. (nicm@) == usr.sbin ========================================================== 09/09 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin vmd ~ vmd.c > typo: should be looking pid == -1 (tedu@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
