Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"

[ebiederm@xmission.com (Eric W. Biederman)]

"linux-os \(Dick Johnson\)" <linux-os@analogic.com> writes:
> ix86 machines need to make many operations just to increment
> or decrement a 64-bit variable, plus the operations are not
> atomic so they need to be protected. The bloat of using 64-bit
> objects in 32-bit machines is very real and a tremendous problem.
> That's why all the stuff in the kernel wasn't 'long long' to
> begin with. It's execution bloat, a.k.a., time expansion that
> is the problem.
>
> Bump a 32-bit variable, addressed from an index register:
>
>  	incl	(%ebx)
>
> Bump a 64-bit variable, addressed the same way.
>
>  	addl	$1,(%ebx)	; Need to add because inc doesn't carry
>  	adcl	$0,4(%ebx)	; Add 0 plus the carry-flag
>
> If an interrupt or context-switch comes between the two operations,
> the result is undefined, NotGood(tm).

No it is well defined it just isn't atomic.  But difference.
The thing is struct resource is accessed less often the file
offsets which are already 64bit.  Basically they are only
used during driver initialization.

So while I agree in general that 64bit values should be avoided
this is one of those places where we can productively use a
64bit value, on a 32bit machine.

To keep using 32bit kernels on the newer x86 machines at some
point this will even become a requirement as 64bit BAR will
actually have 64bit values placed in them.

Eric