Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
On 08/13/2014 01:06 PM, Arnd Bergmann wrote: > On Wednesday 13 August 2014 03:06:53 Ben Hutchings wrote: >>> On the kernel side, it also adds more complexity, where we have to add >>> even more complex compat support for 64bit systems to handle all the >>> various 32bit applications possible. >> [...] >> >> Didn't we need to do this already to support x32? Have compat ioctls >> involving time been botched? > > AFAICT, every ioctl that involves passing a __kernel_ulong_t or > __kernel_ulong_t is potentially broken on x32, and this includes > everything passing a time_t or timespec. > > The problem is that the libc ioctl() function ends up in the kernel's > compat_ioctl handler, which expects the 32-bit ABI, not the 64-bit ABI. > Most other syscalls in x32 however use the 64-bit ABI. > > It works only for drivers that use the same function for .ioctl and > .compat_ioctl, and that encode the size of the data structure correctly > in the ioctl command code. I assume this is how we will do it for all > 32-bit architectures with 64-bit time_t, but on x32 it also concerns > other types that use __kernel_long_t. > OK, super-late reply. Actually we have by and large dealt with that. Sadly this meant an increase in the number of paths with conditional ABI. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
On Wednesday 13 August 2014 03:06:53 Ben Hutchings wrote: > > On the kernel side, it also adds more complexity, where we have to add > > even more complex compat support for 64bit systems to handle all the > > various 32bit applications possible. > [...] > > Didn't we need to do this already to support x32? Have compat ioctls > involving time been botched? AFAICT, every ioctl that involves passing a __kernel_ulong_t or __kernel_ulong_t is potentially broken on x32, and this includes everything passing a time_t or timespec. The problem is that the libc ioctl() function ends up in the kernel's compat_ioctl handler, which expects the 32-bit ABI, not the 64-bit ABI. Most other syscalls in x32 however use the 64-bit ABI. It works only for drivers that use the same function for .ioctl and .compat_ioctl, and that encode the size of the data structure correctly in the ioctl command code. I assume this is how we will do it for all 32-bit architectures with 64-bit time_t, but on x32 it also concerns other types that use __kernel_long_t. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
On 08/12/2014 07:06 PM, Ben Hutchings wrote: > On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote: > [...] >> The downsides here are many. The distros will probably hate this idea, > I certainly hate the idea of adding another 32-bit port to Debian. > I think that it's OK for traditional distros to say 'just upgrade to > 64bit' while you solve the problem for 32-bit embedded systems where > there's probably little demand for supporting multiple ABIs at once. So I don't necessarily disagree, but if the rule really is "we don't break userspace" we will need a solution that at least allows for multiple ABIs from the kernel side, and we can then let distros chose if they want to handle both or not. Even in the embedded world, as usage grows with things like Android, we're starting to see more strict needs for ABI/platform stability (see the ARMv8 SWP discussion from last month). Fancy android based dashboard infotainment systems probably want to both be 2038 safe and run today's unsafe applications (hoping that they get upgraded eventually). > >> as it requires rebuilding the world, and maintaining another legacy >> architecture support. I’m also not completely sure how robust >> multi-arch packaging is in the face of having to handle 3-4 >> architectures on one system. > dpkg multiarch covers this just fine, while I believe RPM is limited to > biarch. > >> On the kernel side, it also adds more complexity, where we have to add >> even more complex compat support for 64bit systems to handle all the >> various 32bit applications possible. > [...] > > Didn't we need to do this already to support x32? Have compat ioctls > involving time been botched? I'm not sure exactly what you mean here, but yea, its very much like supporting something like x32, but its one more to the list and has to be supported on both 32 and 64 architectures. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] 2038 Kernel Summit Discussion Fodder
On Tue, 2014-08-12 at 17:01 -0700, John Stultz wrote: [...] > The downsides here are many. The distros will probably hate this idea, I certainly hate the idea of adding another 32-bit port to Debian. I think that it's OK for traditional distros to say 'just upgrade to 64bit' while you solve the problem for 32-bit embedded systems where there's probably little demand for supporting multiple ABIs at once. > as it requires rebuilding the world, and maintaining another legacy > architecture support. I’m also not completely sure how robust > multi-arch packaging is in the face of having to handle 3-4 > architectures on one system. dpkg multiarch covers this just fine, while I believe RPM is limited to biarch. > On the kernel side, it also adds more complexity, where we have to add > even more complex compat support for 64bit systems to handle all the > various 32bit applications possible. [...] Didn't we need to do this already to support x32? Have compat ioctls involving time been botched? Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
