I have only tested parts of this on arm* and amd64 but I am in general favour as it allows me to boot certain systems in a simulator with a lot less hakery and trouble (which means it boots rather than crashes) ;-)

In D4544#120038, @cem wrote:

Any reason not to use uint64_t instead, per Bruce?

Any reason not to use uint64_t instead, per Bruce?

Ping? If there are no objections, I want to get this in in the next week or so.

Reduce the diff to printf changes and flipping the switch.

Only a few nits still.

Ping? I think this is ready to commit, all comments have been addressed.

Update to address jhb's comments. This should be the final diff.

Remove leftover merge-o marker.

Address jhb's comments, and add libdevinfo/devinfo to the mix.

In D4544#101483, @kib wrote:

I strongly prefer the ~0 over the useless pass over the source code.

In D4544#101238, @bjk wrote:

In D4544#101019, @jhibbits wrote:

In D4544#101018, @cem wrote:

~0 is 0xffffffff on AMD64, not 0xffffffffffffffff. Every replacement of ~0ul by ~0 seems wrong.

On PowerPC, ~0 cast to uintmax_t resolves to 0xffffffffffffffff. I just tested on freefall, too, the following program:
[...]
So your assertion is incorrect.

~0 cast to uintmax_t and ~0 are different values. ~0 has type int.
Values of type int may be implicitly converted to values of type uintmax_t such as by passing in a function argument. C99 (n1256.pdf) 6.3.1.3 says:

"""Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type."""

~0 (as type int) is -1, in our twos-complement implementation. -1 is not representable in the unsigned type, so adding 2**64 to get 0xffffffffffffffff is defined behavior, but relies on some somewhat obscure language in the language specification. It seems like much better style (to me) to directly write the intended value, as Conrad indicated.

In D4544#101019, @jhibbits wrote:

In D4544#101018, @cem wrote:

~0 is 0xffffffff on AMD64, not 0xffffffffffffffff. Every replacement of ~0ul by ~0 seems wrong.

On PowerPC, ~0 cast to uintmax_t resolves to 0xffffffffffffffff. I just tested on freefall, too, the following program:
[...]
So your assertion is incorrect.

In D4544#101018, @cem wrote:

~0 is 0xffffffff on AMD64, not 0xffffffffffffffff. Every replacement of ~0ul by ~0 seems wrong.

~0 is 0xffffffff on AMD64, not 0xffffffffffffffff. Every replacement of ~0ul by ~0 seems wrong.

Update to include man pages and expose rman_res_t to user space.

In D4544#97567, @jhibbits wrote:

Update to s/__rman_res_t/rman_res_t/. No other changes.

Update to s/__rman_res_t/rman_res_t/. No other changes.

I still have to fix the man pages for rman(9), and bus_*_resource(9), coming soon. Looking for additional comments on the code. I'm also building tinderbox with a s/__rman_res_t/rman_res_t/, to make it look nicer.

Add range checking in nexus. It's assumed anything underneath the nexus does range checking within its own bounds.

In D4544#95988, @jhibbits wrote:

Reviewing sys/x86/x86/nexus.c, for example, mem_rman.rm_end could be set to BUS_SPACE_MAXADDR instead of ~0, and that should be sufficient, and a similar change would be possible in the other archs. Thoughts?

In D4544#95988, @jhibbits wrote:

In D4544#95915, @kib wrote:

Could you, please, provide some reasoning behind the way the change is done. As I understand, the intent is to support full range of the resources values for PAE-like configuration, where native platform long type range does not cover e.g. the bus addresses. But, is it intended to provide 64bit resource ranges for e.g. arm or non-PAE i386 ? At least, I did not found any handling of possible mis-allocation of too-high resources. Or, is it not important ?

That may have been an oversight. It's not intended to provide resources which aren't accessible by the architecture. armv7 (more recent cortex's, I think?), i386-PAE, and powerpc (some, specifically mpc7450, and e500v2/e500mc, perhaps others) all support 36-bit addresses. But where it isn't supported, bounds checking should probably be performed (it may already be the case, only later at access time, rather than at allocation time).

In D4544#95915, @kib wrote:

Could you, please, provide some reasoning behind the way the change is done. As I understand, the intent is to support full range of the resources values for PAE-like configuration, where native platform long type range does not cover e.g. the bus addresses. But, is it intended to provide 64bit resource ranges for e.g. arm or non-PAE i386 ? At least, I did not found any handling of possible mis-allocation of too-high resources. Or, is it not important ?

Could you, please, provide some reasoning behind the way the change is done. As I understand, the intent is to support full range of the resources values for PAE-like configuration, where native platform long type range does not cover e.g. the bus addresses. But, is it intended to provide 64bit resource ranges for e.g. arm or non-PAE i386 ? At least, I did not found any handling of possible mis-allocation of too-high resources. Or, is it not important ?

Update diff to address comments.

More like "oops, didn't sanitize my diff completely"