OpenBSD src changes summary for 2017-07-01 ==========================================
games/hack gnu/usr.bin/binutils-2.17 regress/usr.bin sbin/dhclient share/mk sys/arch/amd64/amd64 sys/arch/amd64/include sys/arch/i386/i386 sys/arch/i386/include sys/dev/ic sys/dev/pci usr.bin/file usr.bin/mandoc usr.bin/ssh usr.sbin/pkg_add == games ============================================================= 01/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/games hack ~ Makefile > missed BUILDFIRST. Allow stuff to proceed without depends > as found by krw@ (espie@) == gnu =============================================================== 02/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu usr.bin/binutils-2.17 ~ ld/emulparams/armelf_obsd.sh ~ ld/emulparams/elf32bmip.sh ~ ld/emulparams/elf32bmipn32-defs.sh ~ ld/emulparams/elf32ppc.sh ~ ld/emulparams/elf32ppc_obsd.sh ~ ld/emulparams/elf64_sparc_obsd.sh ~ ld/emulparams/elf64alpha.sh ~ ld/emulparams/elf64btsmip_obsd.sh ~ ld/emulparams/elf64ltsmip_obsd.sh ~ ld/emulparams/elf_i386_obsd.sh ~ ld/emulparams/elf_x86_64_obsd.sh ~ ld/emulparams/hppaobsd.sh ~ ld/emulparams/shelf_obsd.sh ~ ld/scripttempl/elf.sc > provide both TRAP and NOP values for our architectures, then change > elf.sc to FILL .text segment with TRAP. .init/.fini remain NOP FILL. > It is possible that some of these TRAP values aren't perfect yet, but > they can be changed. When doing so also change the ld.script and gap.o > TRAP value. > discussions with mortimer, ok kettenis (deraadt@) == regress =========================================================== 03/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress usr.bin ~ mdoclint/mdoclint ~ mdoclint/mdoclint.1 > delete -p options, the relevant parts are now covered by mandoc; > OK jmc@ (schwarze@) == sbin ============================================================== 04/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin dhclient ~ dhclient.c ~ dhcpd.h ~ dispatch.c ~ kroute.c ~ privsep.c ~ privsep.h > Eliminate multiple socket openings/closings and pass > fd'd from main loops as required. One socket to do > ioctl's per process (called ioctlfd) and one socket to > do route messages per socket (called routefd). > Clean up local variable declaration lists in passing. (krw@) == share ============================================================= 05/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share mk ~ bsd.dep.mk ~ bsd.lib.mk ~ bsd.prog.mk ~ bsd.sys.mk ~ sys.mk > effectively kill depend as an independant target (there are a few corners > where a separate depend step is still needed, mostly gcc3 and mesa). > Use of BUILDFIRST is mostly enough to make sure important stuff is built > first. > Otherwise, this makes use of -M* compiler options to generate dependencies > on the fly. There is a bit of behind-the-scene for targets with several > steps (like yacc and/or libraries) and the compiler needs extra > hand-holding > with assembler files (don't know why, don't care). > Idea based on guenther@'s initial kernel work, loads of input from > drahn, aoyama, tb, etc. > okay tb@ > "why wait" deraadt@ (espie@) == sys =============================================================== 06/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys arch/amd64/amd64 ~ codepatch.c > Use absolute pointers in codepatch entries > Instead of offsets to KERNBASE, store absolute pointers in the > codepatch entries. This makes the resulting kernel a few KB larger on > amd64, but KERNBASE will go away when ASLR is introduced. > Requested by deraadt@ (sf@) arch/amd64/include ~ codepatch.h > Use absolute pointers in codepatch entries > Instead of offsets to KERNBASE, store absolute pointers in the > codepatch entries. This makes the resulting kernel a few KB larger on > amd64, but KERNBASE will go away when ASLR is introduced. > Requested by deraadt@ (sf@) arch/i386/i386 ~ codepatch.c > Use absolute pointers in codepatch entries > Instead of offsets to KERNBASE, store absolute pointers in the > codepatch entries. KERNBASE will go away when ASLR is introduced. > Requested by deraadt@ (sf@) arch/i386/include ~ codepatch.h > Use absolute pointers in codepatch entries > Instead of offsets to KERNBASE, store absolute pointers in the > codepatch entries. KERNBASE will go away when ASLR is introduced. > Requested by deraadt@ (sf@) dev/ic ~ r92creg.h ~ rtwn.c > - Avoid possible use of uninitialized variable; noticed by jsg@ > - Only set value in R92C_FAST_EDCA_CTRL register if the device is > combo WiFi/Bluetooth; confirmed by Yan-Hsuan Chuan from Realtek > - There's no need to set the default value for the R92C_PIFS since > default value is 0x1c; confirmed by Yan-Hsuan Chuan from Realtek > - Disable usb Rx aggregation mode for rtl8188cu/rtl8192cu; > vendor drivers use DMA Rx aggregation mode for > rtl8188cu/rtl8192cu/rtl8188eu > and use USB Rx aggregation mode for later chipsets. > Tested by stsp and me. > ok stsp@ (kevlo@) dev/pci + drm/drm_internal.h > Update inteldrm(4) to code based on Linux 4.4.70. This brings us support > for > Skylake and Cherryview and better support for Broadwell and Valleyview. > Also > adds MST support. Some tweaks to the TTM code and radeondrm(4) to keep it > working with the updated generic DRM code needed for inteldrm(4). > Tested by many. (kettenis@) ~ drm/drm_irq.c ~ drm/drm_linux.c ~ drm/drm_linux.h ~ drm/drm_linux_list.h ~ drm/drm_mm.c ~ drm/drm_mm.h ~ drm/drm_mode.h ~ drm/drm_modes.c ~ drm/drm_rect.c ~ drm/drm_rect.h ~ drm/drm_vma_manager.c ~ drm/files.drm ~ drm/i915_drm.h ~ drm/i915_pciids.h ~ drm/linux_hdmi.h ~ drm/i915/dvo.h ~ drm/i915/dvo_ch7017.c ~ drm/i915/dvo_ch7xxx.c ~ drm/i915/dvo_ivch.c ~ drm/i915/dvo_ns2501.c ~ drm/i915/dvo_sil164.c ~ drm/i915/dvo_tfp410.c ~ drm/i915/i915_dma.c ~ drm/i915/i915_drv.c ~ drm/i915/i915_drv.h ~ drm/i915/i915_gem.c ~ drm/i915/i915_gem_context.c ~ drm/i915/i915_gem_evict.c ~ drm/i915/i915_gem_execbuffer.c ~ drm/i915/i915_gem_gtt.c ~ drm/i915/i915_gem_stolen.c ~ drm/i915/i915_gem_tiling.c ~ drm/i915/i915_gpu_error.c ~ drm/i915/i915_irq.c ~ drm/i915/i915_reg.h ~ drm/i915/i915_suspend.c ~ drm/i915/i915_trace.h ~ drm/i915/intel_bios.c ~ drm/i915/intel_bios.h ~ drm/i915/intel_crt.c ~ drm/i915/intel_ddi.c ~ drm/i915/intel_display.c ~ drm/i915/intel_dp.c ~ drm/i915/intel_drv.h ~ drm/i915/intel_dvo.c ~ drm/i915/intel_fbdev.c ~ drm/i915/intel_hdmi.c ~ drm/i915/intel_i2c.c ~ drm/i915/intel_lvds.c ~ drm/i915/intel_modes.c ~ drm/i915/intel_opregion.c ~ drm/i915/intel_overlay.c ~ drm/i915/intel_panel.c ~ drm/i915/intel_pm.c ~ drm/i915/intel_ringbuffer.c ~ drm/i915/intel_ringbuffer.h ~ drm/i915/intel_sdvo.c ~ drm/i915/intel_sdvo_regs.h ~ drm/i915/intel_sideband.c ~ drm/i915/intel_sprite.c ~ drm/i915/intel_tv.c ~ drm/i915/intel_uncore.c ~ drm/radeon/atombios_crtc.c ~ drm/radeon/atombios_dp.c ~ drm/radeon/atombios_i2c.c ~ drm/radeon/nid.h ~ drm/radeon/r100.c ~ drm/radeon/radeon.h ~ drm/radeon/radeon_connectors.c ~ drm/radeon/radeon_device.c ~ drm/radeon/radeon_display.c ~ drm/radeon/radeon_fb.c ~ drm/radeon/radeon_i2c.c ~ drm/radeon/radeon_irq_kms.c ~ drm/radeon/radeon_kms.c ~ drm/radeon/radeon_legacy_crtc.c ~ drm/radeon/radeon_legacy_encoders.c ~ drm/radeon/radeon_mode.h ~ drm/radeon/radeon_pm.c ~ drm/ttm/ttm_bo_manager.c + drm/drm_linux_atomic.h + drm/drm_mipi_dsi.h + drm/drm_modes.h + drm/drm_modeset_lock.c + drm/drm_modeset_lock.h + drm/drm_panel.c + drm/drm_panel.h + drm/drm_plane_helper.c + drm/drm_plane_helper.h + drm/drm_probe_helper.c + drm/linux_list_sort.c + drm/linux_types.h + drm/linux_ww_mutex.h + drm/i915/i915_cmd_parser.c + drm/i915/i915_gem_batch_pool.c + drm/i915/i915_gem_batch_pool.h + drm/i915/i915_gem_fence.c + drm/i915/i915_gem_gtt.h + drm/i915/i915_gem_render_state.c + drm/i915/i915_gem_render_state.h + drm/i915/i915_gem_userptr.c + drm/i915/i915_guc_reg.h + drm/i915/i915_guc_submission.c + drm/i915/i915_params.c + drm/i915/i915_vgpu.c + drm/i915/i915_vgpu.h + drm/i915/intel_atomic.c + drm/i915/intel_atomic_plane.c + drm/i915/intel_audio.c + drm/i915/intel_csr.c + drm/i915/intel_dp_mst.c + drm/i915/intel_dsi.c + drm/i915/intel_dsi.h + drm/i915/intel_dsi_panel_vbt.c + drm/i915/intel_dsi_pll.c + drm/i915/intel_fbc.c + drm/i915/intel_fifo_underrun.c + drm/i915/intel_frontbuffer.c + drm/i915/intel_gtt.c + drm/i915/intel_guc.h + drm/i915/intel_guc_fwif.h + drm/i915/intel_guc_loader.c + drm/i915/intel_hotplug.c + drm/i915/intel_lrc.c + drm/i915/intel_lrc.h + drm/i915/intel_mocs.c + drm/i915/intel_mocs.h + drm/i915/intel_psr.c + drm/i915/intel_renderstate.h + drm/i915/intel_renderstate_gen6.c + drm/i915/intel_renderstate_gen7.c + drm/i915/intel_renderstate_gen8.c + drm/i915/intel_renderstate_gen9.c + drm/i915/intel_runtime_pm.c + drm/radeon/radeon_dp_auxch.c > Update inteldrm(4) to code based on Linux 4.4.70. This brings us support > for > Skylake and Cherryview and better support for Broadwell and Valleyview. > Also > adds MST support. Some tweaks to the TTM code and radeondrm(4) to keep it > working with the updated generic DRM code needed for inteldrm(4). > Tested by many. (kettenis@) == usr.bin =========================================================== 07/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin file ~ magic-load.c > magicfp is fclosed where it was opened, remove fclose from magic_load() > ok nicm deraadt (brynet@) ~ file.c > close open fd after testing files, ensuring that fd isn't stdin. > ok nicm@ (brynet@) mandoc ~ Makefile ~ main.c ~ manconf.h ~ mandoc.1 ~ mandoc.h ~ manpath.c ~ mansearch.c ~ mdoc_validate.c ~ read.c + mandoc_xr.c + mandoc_xr.h > Basic reporting of .Xrs to manual pages that don't exist > in the base system, inspired by mdoclint(1). > We are able to do this because (1) the -mdoc parser, the -Tlint validator, > and the man(1) manual page lookup code are all in the same program > and (2) the mandoc.db(5) database format allows fast lookup. > Feedback from, previous versions tested by, and OK jmc@. > A few features will be added to this in the tree, step by step. (schwarze@) ~ main.c > When checking the validity of cross references with -Tlint, > fall back from database search to file system search > just like man(1) does when looking up manuals. > This is not too expensive because on a system having up-to-date > mandoc.db(5) files, it only prolongs the time needed to check > *invalid* references - and you are supposed to have many of those, > right? And on a system with missing or invalid mandoc.db(5) files, > spending a bit of time and warning loudly about the real problem > is also better than quickly issuing bogus warnings about cross > references that are actually valid. (schwarze@) ~ main.c > When checking cross references with -Tlint, ultimately fall back to > looking in the current working directory. Not a security issue > because the files are never open(2)ed, only access(2)ed. > Requested by jmc@ and inspired by mdoclint(1). > This cannot be perfect because it only works for files having the > exact filename ./pagename.sec - mandoc has no way to figure out > which files might contain a manual for multiple names, or that files > in autohell might be called ./pagename.man.in instead, or which > subdirectories might contain additional source files. Also, it may > hide messages if you have bogus stuff lying around in the directory > where you run mandoc -Tlint. But jmc@ considers it important, and > good enough for everyday use. > Also avoid leaking the memory for the file name while here. (schwarze@) ssh ~ authfd.c ~ authfile.c ~ rsa.c ~ rsa.h ~ ssh-add.c ~ ssh-agent.c ~ ssh-keygen.c ~ ssh-rsa.c ~ sshconnect.c ~ sshd.c ~ sshkey.c ~ sshkey.h ~ lib/Makefile > remove post-SSHv1 removal dead code from rsa.c and merge the > remaining bit that it still used into ssh-rsa.c; ok markus (djm@) - rsa.c - rsa.h > actually remove these files (djm@) == usr.sbin ========================================================== 08/08 == http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin pkg_add ~ OpenBSD/AddDelete.pm > go thru POSIX::Termios to turn off kerninfo. > wasn't even aware that stuff existed, thanks nicm@ > NOKERNINFO hardcoded, because it's not in the POSIX module, shouldn't be > a big issue. > okay millert@ (espie@) =============================================================================== _______________________________________________ odc mailing list [email protected] http://www.squish.net/mailman/listinfo/odc
