[odc] Daily src changes for 2007-11-15
ODC
auto at squish.net
Fri Nov 16 07:00:01 GMT 2007
OpenBSD src changes summary for 2007-11-15
==========================================
distrib/sets sys/arch/alpha/include
sys/arch/amd64/amd64 sys/arch/amd64/conf
sys/arch/amd64/include sys/arch/aviion/aviion
sys/arch/i386/conf sys/arch/i386/i386
sys/arch/i386/include sys/arch/luna88k/luna88k
sys/arch/m88k/include sys/arch/m88k/m88k
sys/arch/mvme88k/mvme88k sys/arch/sparc64/dev
sys/conf sys/dev/acpi
sys/dev/cardbus sys/dev/ic
sys/dev/pci sys/dev/usb
sys/kern sys/msdosfs
usr.sbin/hoststated
== distrib =========================================================== 01/03 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/distrib
sets
~ lists/base/md.sparc64 ~ lists/base/mi
~ lists/comp/md.sparc64 ~ lists/etc/mi
> sync (deraadt@)
== sys =============================================================== 02/03 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/sys
arch/alpha/include
~ cpu.h
> ``stastic'' is a fantastic typo. (miod@)
arch/amd64/amd64
~ acpi_machdep.c
> remove the #ifdef ACPI_ENABLE. the EC codepath is either safe enough (and
> will be improved), or it is unsafe because AML assumes it must be there
> ok almost everyone (deraadt@)
arch/amd64/conf
~ GENERIC ~ RAMDISK
~ RAMDISK_CD
> enable most acpi functionality by default. now instead of 'enable acpi',
> you use 'disable acpi' or 'disable apm' withn you encounter problems
> (depending on which kind of problems). if we work hard enough, this can
> remain the situation by the time we ship the next release. otherwise, we
> will re-disable acpi... so let's crackin' (deraadt@)
arch/amd64/include
~ smbiosvar.h
> Add struct for processors.
> ok deraadt (marco@)
~ smbiosvar.h
> oops, processor structs need to be __packed.
> prompted by deraadt (marco@)
~ smbiosvar.h
> Clarify when smbios added multi core support and add the missing string
> designations.
> ok deraadt (marco@)
~ smbiosvar.h
> Split CPUID into 2 32 bit fields.
> ok deraadt (marco@)
arch/aviion/aviion
~ locore.S ~ machdep.c
> Stop referring the initial kernel stack as the ``interrupt stack''. It's
> been years since it has last been used for that purpose, so name it the
> initialization/startup stack.
> While there, do not store the initialization stack in cpu_info, and have
> secondary_pre_main() return its value so that the bootstrap code does not
> need to fetch it from cpu_info.
> This might be reconsidered when the startup stacks will be freed after they
> are not used anymore, but there are more things to do first. (miod@)
~ eh.S
> At last, port the mvme88k eh.S r1.66 fixes to aviion. (miod@)
arch/i386/conf
~ GENERIC ~ RAMDISK
~ RAMDISKB ~ RAMDISKC
~ RAMDISK_CD
> enable most acpi functionality by default. now instead of 'enable acpi',
> you use 'disable acpi' or 'disable apm' withn you encounter problems
> (depending on which kind of problems). if we work hard enough, this can
> remain the situation by the time we ship the next release. otherwise, we
> will re-disable acpi... so let's crackin' (deraadt@)
arch/i386/i386
~ bios.c
> in MP kernels, use smbios to count number of cpus. if > 1 disable apm, so
> that acpi can get a chance at controlling the machine.
> done with marco, and even tested on the nastiest case: smbios <2.5 w/ HTT
> (deraadt@)
~ acpi_machdep.c
> remove the #ifdef ACPI_ENABLE. the EC codepath is either safe enough (and
> will be improved), or it is unsafe because AML assumes it must be there
> ok almost everyone (deraadt@)
arch/i386/include
~ smbiosvar.h
> Add struct for processors.
> ok deraadt (marco@)
~ smbiosvar.h
> oops, processor structs need to be __packed.
> prompted by deraadt (marco@)
~ smbiosvar.h
> Clarify when smbios added multi core support and add the missing string
> designations.
> ok deraadt (marco@)
~ smbiosvar.h
> Split CPUID into 2 32 bit fields.
> ok deraadt (marco@)
arch/luna88k/luna88k
~ locore.S ~ machdep.c
> Stop referring the initial kernel stack as the ``interrupt stack''. It's
> been years since it has last been used for that purpose, so name it the
> initialization/startup stack.
> While there, do not store the initialization stack in cpu_info, and have
> secondary_pre_main() return its value so that the bootstrap code does not
> need to fetch it from cpu_info.
> This might be reconsidered when the startup stacks will be freed after they
> are not used anymore, but there are more things to do first. (miod@)
arch/m88k/include
~ cpu.h
> Stop referring the initial kernel stack as the ``interrupt stack''. It's
> been years since it has last been used for that purpose, so name it the
> initialization/startup stack.
> While there, do not store the initialization stack in cpu_info, and have
> secondary_pre_main() return its value so that the bootstrap code does not
> need to fetch it from cpu_info.
> This might be reconsidered when the startup stacks will be freed after they
> are not used anymore, but there are more things to do first. (miod@)
~ frame.h
> Resolve the struct trapframe tf_mode/tf_flags duality by getting rid of
> the tf_mode name. This field only contains flags used internally by the
> exception processing code. (miod@)
arch/m88k/m88k
~ eh_common.S ~ genassym.cf
> Stop referring the initial kernel stack as the ``interrupt stack''. It's
> been years since it has last been used for that purpose, so name it the
> initialization/startup stack.
> While there, do not store the initialization stack in cpu_info, and have
> secondary_pre_main() return its value so that the bootstrap code does not
> need to fetch it from cpu_info.
> This might be reconsidered when the startup stacks will be freed after they
> are not used anymore, but there are more things to do first. (miod@)
~ eh_common.S
> Make a few end-of-trap-handling symbols global, to get better ddb traces.
> Also, pick better symbol names in the sir/ast processing. (miod@)
~ eh_common.S ~ genassym.cf
~ m88k_machdep.c
> Check for curcpu()->ci_softintr being nonzero before invoking dosoftint(),
> in the common case, this saves us two potentially expensive setipl() calls.
> (miod@)
~ eh_common.S ~ genassym.cf
~ m88k_machdep.c
> Resolve the struct trapframe tf_mode/tf_flags duality by getting rid of
> the tf_mode name. This field only contains flags used internally by the
> exception processing code. (miod@)
arch/mvme88k/mvme88k
~ locore.S ~ machdep.c
> Stop referring the initial kernel stack as the ``interrupt stack''. It's
> been years since it has last been used for that purpose, so name it the
> initialization/startup stack.
> While there, do not store the initialization stack in cpu_info, and have
> secondary_pre_main() return its value so that the bootstrap code does not
> need to fetch it from cpu_info.
> This might be reconsidered when the startup stacks will be freed after they
> are not used anymore, but there are more things to do first. (miod@)
arch/sparc64/dev
~ com_ebus.c
> Attach to "rsc-console". Hopefuly this will give us a proper console on
> the Sun Fire 280R/V480/V880 when the console is directed to the RSC card.
> (kettenis@)
conf
~ files
> New driver for Ralink RT2860 chipset.
> Attaches as 'ral' as it shares the PCI and CardBus frontends with
> RT2560 and RT2661 though it is actually a separate driver.
> Requires a firmware that can't be redistributed with the base system
> due to license restrictions (exact same license as iwn(4) firmware).
> The 802.11n capabilities not yet supported (except MIMO).
> Great thanks to Sam Fourman Jr for donating hardware.
> ok deraadt@ (damien@)
dev/acpi
~ dsdt.c
> don't waste our time telling the aml that we are OpenBSD; it will never
> make a good decision based on that; ok kettenis canacar (deraadt@)
~ acpicpu.c
> Nicer dmesg output.
> From Oleg Safiullin (form@)
> ok deraadt (mikeb@)
~ acpi.c ~ acpimadt.c
~ acpivar.h
> Make acpicpu(4) attach to the existing CPUs only.
> Problem reported by form at . Fix idea by kettenis at .
> Lots of help from deraadt at . Tested by deraadt@, form@ and me.
> ok deraadt marco (mikeb@)
~ acpi.c
> remove the #ifdef ACPI_ENABLE. the EC codepath is either safe enough (and
> will be improved), or it is unsafe because AML assumes it must be there
> ok almost everyone (deraadt@)
dev/cardbus
~ if_ral_cardbus.c
> New driver for Ralink RT2860 chipset.
> Attaches as 'ral' as it shares the PCI and CardBus frontends with
> RT2560 and RT2661 though it is actually a separate driver.
> Requires a firmware that can't be redistributed with the base system
> due to license restrictions (exact same license as iwn(4) firmware).
> The 802.11n capabilities not yet supported (except MIMO).
> Great thanks to Sam Fourman Jr for donating hardware.
> ok deraadt@ (damien@)
dev/ic
+ rt2860.c + rt2860reg.h
+ rt2860var.h
> New driver for Ralink RT2860 chipset.
> Attaches as 'ral' as it shares the PCI and CardBus frontends with
> RT2560 and RT2661 though it is actually a separate driver.
> Requires a firmware that can't be redistributed with the base system
> due to license restrictions (exact same license as iwn(4) firmware).
> The 802.11n capabilities not yet supported (except MIMO).
> Great thanks to Sam Fourman Jr for donating hardware.
> ok deraadt@ (damien@)
dev/pci
~ if_ral_pci.c
> New driver for Ralink RT2860 chipset.
> Attaches as 'ral' as it shares the PCI and CardBus frontends with
> RT2560 and RT2661 though it is actually a separate driver.
> Requires a firmware that can't be redistributed with the base system
> due to license restrictions (exact same license as iwn(4) firmware).
> The 802.11n capabilities not yet supported (except MIMO).
> Great thanks to Sam Fourman Jr for donating hardware.
> ok deraadt@ (damien@)
~ pcidevs.h ~ pcidevs_data.h
> sync (deraadt@)
~ if_ral_pci.c
> match expresscard ral (deraadt@)
~ pcidevs
> ralink N expresscard model (deraadt@)
dev/usb
~ usbdevs.h ~ usbdevs_data.h
> sync (deraadt@)
~ usbdevs
> more devices... all the time (deraadt@)
kern
~ vfs_subr.c
> newline before syncing disks is way prettier (deraadt@)
msdosfs
~ msdosfs_vfsops.c
> read boot sector as 4K block, because of new ipod nano
> from Alexey Vatchenko; ok tom (deraadt@)
== usr.sbin ========================================================== 03/03 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin
hoststated
~ hoststated.c ~ parse.y
~ pfe.c
> Do not insert proto_default inside the dynamically alloced protocol queue.
> Handle it as a special case in the one place where it actually matters
> instead. (pyr@)
===============================================================================
More information about the odc
mailing list