Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 18 Apr 2003 14:12:27 -0500 (CDT) | From | Kai Germaschewski <> | Subject | Re: [PATCH] struct loop_info64 |
| |
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/
| ![\](/images/icornerr.gif) |