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
|
232896 |
12-Mar-2012 |
jmallett |
o) Use ABI, not ISA_* options, to determine whether to compile bits if libkern required for the ABI the kernel is being built for. XXX This is implemented in a kind-of nasty way that involves including source files, but it's still an improvement. o) Retire ISA_* options since they're unused and were always wrong.
|
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.
|
202032 |
10-Jan-2010 |
imp |
Merge from projects/mips to head by hand:
Merge support for very early alchemy port. I wouldn't merge this except I don't want it to get lost when we retire projects/mips. Should be consiered pre-alpha at this stage. Also, alchemy is now owned by rmi, but started out life as a separate processor line, so I'm leaving it in its own directory rather than try to shoe-horn it into the unrelated rmi directory. Its future location is an open question.
|