Recently, we had a discussion on the linux-atm list about the best approach
for passing kernel pointers to user space, and back. The idea is as follows:
There are a few demon processes which assist the kernel in performing
low-level tasks, a bit like cardmgr and such. The demons and the kernel
communicate about some set of objects (e.g. an ATM connection descriptor).
The reference used to identify that object is a pointer to the kernel's
data structure. The protocol spoken between kernel and demons makes of
course sure that no stale references can be used, and such pointers are
never exposed to regular user programs. This approach allows the kernel
to look up data structures extremely quickly and without any list-walking
and locking issues.
The problem: on some architectures, user space and kernel have different
pointer lengths. E.g.
unsigned long void * long long
i386 kernel 32 32 64
user space 32 32 64
sparc64 kernel 64 64 64
user space 32 32 64
"generic 64bit" kernel 64 64 64
user space 64 64 64
("generic 64bit" is an architecture where everything, except maybe int,
is 64 bit. I think this roughly represents the Alpha.)
The only type which is at least sizeof(void *), and where kernel and
user space have the same size everywhere, seems to be long long .
There are also a few typedef'ed types (e.g. loff_t), which have similar
properties.
My question is now if it's wise to use long long or some of its
equivalents all the time, or if we'd be better off just using a 64
bit type on architecturs where it may natively exist. (1)
My main concerns with using long long everywhere are:
- can I expect the compilers on all platforms supported by Linux
to do something reasonable when encountering long long ? (2)
- in particular, can they do correct comparisons (for lookups)
and simple math (for hashes) on long long ?
If long long isn't an option, is there any other "standard" type
that has the desired properties ?
(1) with the notable exception of sparc32, because user space can't
easily tell sparc32 from sparc64, so it has to be long long
there too.
(2) For this discussion, we can assume the "standard" system
development compiler, which should be some gcc/egcs variant.
BTW, the current solution is a typedef'ed type which is private to
the ATM code, and which is normally long but becomes long long
on sparc32/sparc64. This will of course break as soon as the next
architecture comes along, where sizeof(long) < sizeof(void *).
Thanks,
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:20 EST