295832 |
20-Feb-2016 |
jhibbits |
Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.
This simplifies checking for default resource range for bus_alloc_resource(), and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to uintmax_t.
Discussed with: jhb Suggested by: marcel
|
294883 |
27-Jan-2016 |
jhibbits |
Convert rman to use rman_res_t instead of u_long
Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of u_long.
Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI.
Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
|
232853 |
12-Mar-2012 |
jmallett |
Remove platform APIs which are not used by any code and which had only stub implementations or no implementation on all platforms.
Some of these functions might be good ideas, but their semantics were unclear given the lack of implementation, and an unlucky porter could be fooled into trying to implement them or, worse, being baffled when something like platform_trap_enter() failed to be called.
|
232615 |
06-Mar-2012 |
jmallett |
At the risk of reducing source compatibility with old NetBSD and Sprite: o) Get rid of some unused macros related to features we don't intend to provide. o) Get rid of macro definitions for MIPS-I CPUs. We are not likely to support anything that predartes MIPS-III. o) Respell MIPS3_* macros as MIPS_*, which is how most of them were being used already. o) Eliminate a duplicate and mostly-unused set of exception vector macros.
There's still considerable duplication and lots more obsolete in our headers, but this reduces one of the larger files to a size where one could reckon about the correctness of its contents with a mere few hours of contemplation.
There is, of course, a question of whether we need definitions for fields, registers and configurations that we are unlikely to ever use or implement, even if they're not obsolete since 1991. FreeBSD is not a processor reference manual, and things that aren't used may be wrong, or may be duplicated because nobody could possibly actually know whether they're already defined.
|
222813 |
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
218591 |
12-Feb-2011 |
jmallett |
Allow the platform code to return a bitmask of running cores rather than just a number of cores, this allows for a sparse set of CPUs. Implement support for sparse core masks on Octeon.
XXX jeff@ suggests that all_cpus should include cores that are offline or running other applications/OSes, so the platform API should be further extended to allow us to set all_cpus to include all cores that are physically-present as opposed to only those that are running FreeBSD.
Submitted by: Bhanu Prakash (with modifications) Reviewed by: jchandra Glanced at by: kib, jeff, jhb
|
212989 |
22-Sep-2010 |
neel |
Enforce that 'pmap_kenter()' is only used to establish cacheable mappings.
Mappings with other cacheability attributes can be established, if needed, by using 'pmap_kenter_attr()'.
Suggested by: jchandra, imp
|