Hi, On Fri, 24 Jan 2003, Jens Owen wrote: > > Keep in mind that the TDFX driver was ported to IA-64 many moons ago. I > know Don Dugger had 32 bit applications (running in a 32 bit subsystem, > w/ a 32 bit client side driver) direct rendering to the tdfx display > controlled by a 64 bit server running on a 64 bit kernel.
Cool, sounds like he has done good work for the TDFX driver, I'm new to dri, but sounds like a thing to look for example code. > If I recall there was some kind of 32bit to 64bit thunking layer for > kernel calls. Yes, all 64-bit Linux I know has an 32-bit compatibility layer in the kernel, you can find the files using find /usr/src/linux/arch|grep 32. For x86_64, most of it is in arch/x86_64/ia32/*.c The compatibility layer has different levels it needs to cover: the 32-bit user system entry and leave, mapping of 32-bit syscalls to the native 64-bit kernel syscalls(needs a table of 32-bit syscall numbers with funtions which get the 32-bit system call args, call the 64-bit native functions using the 64-bit values and copy&converting the returns back to 32-bit), mapping of 32-bit ioctls to functions which copy the 32-bit structs to the 64-bit structs and back for return, and other nasty things like ptrace... > TDFX didn't required any AGP support, so there's work to be done there. Seems so, the x86_64 developers should be able to give some more info, e.g. I've read in arch/x86_64/kernel/pci-gart.c that the AMD Hammer has an IOMMU in the northbridge and it says that it can support PCI devices which can only support 32bit addresses on systems >4GB using the IOMMU. Nonetheless, if there is no IOMMU, then pages for HW-access would need to be allocated below 4GB. If only very few space is needed, kmalloc can be used with GFP_DMA which tells it to allocate below MAX_DMA_ADDRESS which is defined to 16MB on i386(24 address lines). x86_64 seems to support the same GFP_DMA range for compatibility. >From what I have seen about 32-bit compatibility, it's best to have fixed-size data structures without 64-bit values, especially no pointers in structures which point to other data needed and also take care when adding other data types which include struct timeval which contain 32-bit seconds on 32-bit systems and 64-bit seconds(past 2038...) on 64-bit systems. If this is given, then the compatibility layer should be very easy, small and fast, no need to copy&convert 32-bit struct to 64-bit struct forth and back and no two separate struct definitions to handle. Bernd PS: I don't know much about AGP, DRI and the internals of AMD Hammer Systems, so please forgive me if I overlooked something obvious. PPS: If you want to align/use small data, I think it would be good to use something like this: uint32, uint16, uint8, uint8, uint32, ... instead of shifting or accessing bits outside of the byte range because this may cause endian problems with on Macs/PPC. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
