svn commit: r297000 - in head: . sys/arm/xscale/ixp425 sys/arm/xscale/pxa sys/compat/ndis sys/dev/acpica sys/dev/advansys sys/dev/atkbdc sys/dev/bxe sys/dev/cardbus sys/dev/ctau sys/dev/ed sys/dev/...
Author: jhibbits Date: Fri Mar 18 01:28:41 2016 New Revision: 297000 URL: https://svnweb.freebsd.org/changeset/base/297000 Log: Use uintmax_t (typedef'd to rman_res_t type) for rman ranges. On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xf, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544 Modified: head/UPDATING head/sys/arm/xscale/ixp425/avila_ata.c head/sys/arm/xscale/ixp425/ixp425.c head/sys/arm/xscale/pxa/pxa_obio.c head/sys/compat/ndis/kern_ndis.c head/sys/dev/acpica/acpi.c head/sys/dev/acpica/acpi_hpet.c head/sys/dev/acpica/acpi_timer.c head/sys/dev/advansys/adv_isa.c head/sys/dev/atkbdc/atkbdc_subr.c head/sys/dev/bxe/bxe.c head/sys/dev/cardbus/cardbus_cis.c head/sys/dev/ctau/if_ct.c head/sys/dev/ed/if_ed_3c503.c head/sys/dev/ed/if_ed_cbus.c head/sys/dev/fdt/simplebus.c head/sys/dev/iir/iir_pci.c head/sys/dev/mca/mca_bus.c head/sys/dev/mxge/if_mxge.c head/sys/dev/ofw/ofwbus.c head/sys/dev/pccard/pccard.c head/sys/dev/pccard/pccard_cis.c head/sys/dev/pccbb/pccbb.c head/sys/dev/pccbb/pccbb_pci.c head/sys/dev/pci/pci.c head/sys/dev/pci/pci_pci.c head/sys/dev/pci/pci_subr.c head/sys/dev/ppc/ppc.c head/sys/dev/proto/proto_bus_isa.c head/sys/dev/sound/isa/ad1816.c head/sys/dev/sound/isa/ess.c head/sys/dev/sound/isa/mss.c head/sys/dev/sound/isa/sb16.c head/sys/dev/sound/isa/sb8.c head/sys/dev/sound/pci/als4000.c head/sys/dev/sound/pci/atiixp.c head/sys/dev/sound/pci/aureal.c head/sys/dev/sound/pci/cmi.c head/sys/dev/sound/pci/cs4281.c head/sys/dev/sound/pci/csapcm.c head/sys/dev/sound/pci/ds1.c head/sys/dev/sound/pci/emu10k1.c head/sys/dev/sound/pci/emu10kx.c head/sys/dev/sound/pci/envy24.c head/sys/dev/sound/pci/envy24ht.c head/sys/dev/sound/pci/es137x.c head/sys/dev/sound/pci/fm801.c head/sys/dev/sound/pci/hdspe-pcm.c head/sys/dev/sound/pci/ich.c head/sys/dev/sound/pci/maestro.c head/sys/dev/sound/pci/maestro3.c head/sys/dev/sound/pci/neomagic.c head/sys/dev/sound/pci/solo.c head/sys/dev/sound/pci/t4dwave.c head/sys/dev/sound/pci/via8233.c head/sys/dev/sound/pci/via82c686.c head/sys/dev/sound/pci/vibes.c head/sys/dev/wl/if_wl.c head/sys/dev/xe/if_xe.c head/sys/dev/xe/if_xe_pccard.c head/sys/kern/subr_rman.c head/sys/mips/atheros/apb.c head/sys/mips/mips/nexus.c head/sys/mips/nlm/xlp_pci.c head/sys/mips/nlm/xlp_simplebus.c head/sys/mips/rmi/iodi.c head/sys/mips/rmi/xlr_pci.c head/sys/powerpc/mpc85xx/lbc.c head/sys/powerpc/ofw/ofw_pci.c head/sys/powerpc/powermac/uninorth.c head/sys/powerpc/powerpc/nexus.c head/sys/sparc64/pci/apb.c head/sys/sys/_types.h head/sys/sys/param.h head/sys/x86/x86/io_apic.c head/usr.sbin/devinfo/devinfo.c Modified: head/UPDATING == --- head/UPDATING Fri Mar 18 01:26:55 2016(r296999) +++ head/UPDATING Fri Mar 18 01:28:41 2016(r297000) @@ -31,6 +31,10 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 11 disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20160317: + Resource range types have grown from unsigned long to uintmax_t. All + drivers, and anything using
Re: svn commit: r297000 - in head: . sys/arm/xscale/ixp425 sys/arm/xscale/pxa sys/compat/ndis sys/dev/acpica sys/dev/advansys sys/dev/atkbdc sys/dev/bxe sys/dev/cardbus sys/dev/ctau sys/dev/ed sys/dev
On Friday, March 18, 2016 01:28:41 AM Justin Hibbits wrote: > Author: jhibbits > Date: Fri Mar 18 01:28:41 2016 > New Revision: 297000 > URL: https://svnweb.freebsd.org/changeset/base/297000 > > Log: > Use uintmax_t (typedef'd to rman_res_t type) for rman ranges. > > On some architectures, u_long isn't large enough for resource definitions. > Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, > but > type `long' is only 32-bit. This extends rman's resources to uintmax_t. > With > this change, any resource can feasibly be placed anywhere in physical memory > (within the constraints of the driver). > > Why uintmax_t and not something machine dependent, or uint64_t? Though it's > possible for uintmax_t to grow, it's highly unlikely it will become 128-bit > on > 32-bit architectures. 64-bit architectures should have plenty of RAM to > absorb > the increase on resource sizes if and when this occurs, and the number of > resources on memory-constrained systems should be sufficiently small as to > not > pose a drastic overhead. That being said, uintmax_t was chosen for source > clarity. If it's specified as uint64_t, all printf()-like calls would > either > need casts to uintmax_t, or be littered with PRI*64 macros. Casts to > uintmax_t > aren't horrible, but it would also bake into the API for > resource_list_print_type() either a hidden assumption that entries get cast > to > uintmax_t for printing, or these calls would need the PRI*64 macros. Since > source code is meant to be read more often than written, I chose the > clearest > path of simply using uintmax_t. > > Tested on a PowerPC p5020-based board, which places all device resources in > 0xf, and has 8GB RAM. > Regression tested on qemu-system-i386 > Regression tested on qemu-system-mips (malta profile) > > Tested PAE and devinfo on virtualbox (live CD) > > Special thanks to bz for his testing on ARM. > > Reviewed By: bz, jhb (previous) > Relnotes: Yes > Sponsored by: Alex Perez/Inertial Computing > Differential Revision: https://reviews.freebsd.org/D4544 Thank you for chasing this down to completion. It removes quite a few hacks from the PAE case. Thank you also for being patient when I asked you to split the changes up, rearrange things, etc. :) -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
