On Fri, 18 Apr 2003, Greg KH wrote:
> On Fri, Apr 18, 2003 at 10:55:21AM -0700, Linus Torvalds wrote:
> >
> > But we really should have a __ptr64 type too. There's just no sane way to
> > tell gcc about it without requireing casts, which is inconvenient (which
> > means that right now it you just have to use __u64 for pointers if you
> > want to be able to share the structure across 32/64-bit architectures).
>
> I think that's what Stephan and Rusty tried to do with the
> kernel_ulong_t typedef in include/linux/mod_devicetable.h.
>
> Maybe that typedef could be changed into the __ptr64 type? Stephan?
I think kernel_ulong_t serves a slightly different purpose, very specific
to the module device table stuff, i.e. it represents an unsigned long in
the kernel ABI.
It normally contains a kernel pointer, as such it's inaccessible and
worthless to userspace, anyway. The reason for its existance is the fact
the scripts/file2alias needs to parse the contents of the table in the
object file and thus needs the distance between entries, which is
sizeof(struct foo_device_id).
So as opposed to the __ptr64, we don't actually want to pass a pointer
between user and kernel space here, nor is the size of this field constant
at 64 bits.
It shares the problems with __ptr64, though: Making this field always 64
bits large would simplify the userspace code a little, since it wouldn't
need to know the size of a kernel pointer / unsigned long. However, it
still needs to know the endianness, so we don't gain too much. (That's
different from the normal compat issues, where I suppose the endianness is
the same for 32/64 bit mode).
However, the real problem is that we want a type which can be cast to a
pointer, which unsigned long is, but a general __ptr64 cannot be - on 32
bits archs one would need to cast like
(struct foo *) (unsigned long) drv->driver_data
instead of just
(struct foo *) drv->driver_data
which is ugly (and I think the problem Linus referred to).
(A last comment, btw: getting the size right is not all, alignment issues
in arrays of structs are much more subtle. struct {pci,usb}_device_id
happen to get it right since kernel_ulong_t are aligned to a 8 byte
boundary, but it's rather fragile).
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:25 EST