* architecture conditional
@ 2017-10-16 10:37 Tobin C. Harding
2017-10-16 16:10 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Tobin C. Harding @ 2017-10-16 10:37 UTC (permalink / raw)
To: kernelnewbies
What is the correct way to write code that is conditionally compiled depending on 32/64 bit?
I found
CONFIG_X86_64
CONFIG_64BIT
Do we still support other word sizes?
thanks,
Tobin.
^ permalink raw reply [flat|nested] 4+ messages in thread
* architecture conditional
2017-10-16 10:37 architecture conditional Tobin C. Harding
@ 2017-10-16 16:10 ` Greg KH
2017-10-16 20:36 ` Tobin C. Harding
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2017-10-16 16:10 UTC (permalink / raw)
To: kernelnewbies
On Mon, Oct 16, 2017 at 09:37:17PM +1100, Tobin C. Harding wrote:
> What is the correct way to write code that is conditionally compiled depending on 32/64 bit?
Not to write code that is dependent on such a thing in the first place
:)
> I found
>
> CONFIG_X86_64
> CONFIG_64BIT
>
> Do we still support other word sizes?
No, but those are not what you should be looking for, it all depends on
the architecture and where in the kernel you need to do this (arch
specific code, driver, kernel, networking, etc.)
Any specific hints on why you think you need this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 4+ messages in thread
* architecture conditional
2017-10-16 16:10 ` Greg KH
@ 2017-10-16 20:36 ` Tobin C. Harding
2017-10-16 21:09 ` valdis.kletnieks at vt.edu
0 siblings, 1 reply; 4+ messages in thread
From: Tobin C. Harding @ 2017-10-16 20:36 UTC (permalink / raw)
To: kernelnewbies
On Mon, Oct 16, 2017 at 06:10:53PM +0200, Greg KH wrote:
> On Mon, Oct 16, 2017 at 09:37:17PM +1100, Tobin C. Harding wrote:
> > What is the correct way to write code that is conditionally compiled depending on 32/64 bit?
>
> Not to write code that is dependent on such a thing in the first place
> :)
>
> > I found
> >
> > CONFIG_X86_64
> > CONFIG_64BIT
> >
> > Do we still support other word sizes?
>
> No, but those are not what you should be looking for, it all depends on
> the architecture and where in the kernel you need to do this (arch
> specific code, driver, kernel, networking, etc.)
>
> Any specific hints on why you think you need this?
Hashing the kernel pointers. Wanting to call the SipHash functions. We need to call a different
function depending on the size of the pointer.
u64 siphash_1u64(const u64 a, const siphash_key_t *key);
u64 siphash_1u32(const u32 a, const siphash_key_t *key);
Jason A. Donenfeld suggested (offered to) add a helper function in siphash, along the lines of
siphash_1u() but we still need to know the exact size of the return value (so we can drop half of it
if it is 64 bits). We just want a 32 bit identifier returned after hashing the address.
thanks,
Tobin.
^ permalink raw reply [flat|nested] 4+ messages in thread
* architecture conditional
2017-10-16 20:36 ` Tobin C. Harding
@ 2017-10-16 21:09 ` valdis.kletnieks at vt.edu
0 siblings, 0 replies; 4+ messages in thread
From: valdis.kletnieks at vt.edu @ 2017-10-16 21:09 UTC (permalink / raw)
To: kernelnewbies
On Tue, 17 Oct 2017 07:36:42 +1100, "Tobin C. Harding" said:
> Jason A. Donenfeld suggested (offered to) add a helper function in siphash, along the lines of
> siphash_1u() but we still need to know the exact size of the return value (so we can drop half of it
> if it is 64 bits). We just want a 32 bit identifier returned after hashing the address.
Why is truncating to 32 bits needed? Just either use a 32/64 bit value as
appropriate for the architecture, or just declare "This is 32 bits regardless"
or "this is 64 regardless".
What problem are you trying to solve by hashing addresses? (Hint - the two
in-kernel users of siphash are net/core/secure_seq.c and net/ipv4/syncookies.c,
both of which know how big the hashed value has to be, and the size isn't
architecture dependent as it's fixed by the size of a protocol header field)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171016/e046b4a4/attachment.bin
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-10-16 21:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-16 10:37 architecture conditional Tobin C. Harding
2017-10-16 16:10 ` Greg KH
2017-10-16 20:36 ` Tobin C. Harding
2017-10-16 21:09 ` valdis.kletnieks at vt.edu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.