Messages in this thread | | | From | "Pinski, Andrew" <> | Subject | Re: [PATCH v4 00/24] ILP32 for ARM64 | Date | Thu, 16 Apr 2015 11:33:49 +0000 |
| |
> On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > > Just for the record (and to avoid anyone wasting their time on what’s available > today): we are migrating this over to option (a) now, even though we would > prefer to see option (b) implemented. > > If we get a consensus on (b) in the next couple of days, we’ll redo things for > option (b). If not, we will have an implementation for option (a) available that > we can hopefully all agree on merging.
I don't think either a or b are good in the long run. There are only a few places where long should be 32bit rather than 64bit. The non-time_t field of timespec is the only one I can think of. The rest are valid and good idea to stay as 64bit. Including the limits. I think this whole discussion should have happened over a year ago. And I thought c was decided back then. I had even implemented a originally and then asked to move over to c. So I am a bit upset now we are making this kind of huge changes to the abi a year after the original posting of the patch.
Also why does it takes over a year to accept patches into the linux kernel when it takes much less time to make huge changes into gcc (pointer plus is an example which took only a few months to accept and it was an infrastructure change and this is not even an infrastructure change).
Thanks, Andrew
> > Best, > Phil. > >> On 16 Apr 2015, at 13:03, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >> On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >>> We've just started to bootstrap openSUSE for ILP32 with the non-final >>> abi. However, keep in mind that at least for us bootstrapping is a >>> manual process. So changing syscall numbers means we'll need to go >>> through the manual process again. >>> >>> So if you need any help on getting you an environment that allows you to >>> build LTP with whatever syscall abi people come up with, feel free to >>> poke Andreas or me. >> >> Thanks for the offer. It's great to see a full distro being built (even >> though no commitment). >> >> But I'm a bit worried that people started using these patches and we >> haven't agreed on the ABI yet (well, for a while we thought that the x32 >> approach was fine until I've seen objections from others). >> >> Maybe a quick poll on the options, ignoring syscall number details (we >> go for the generic ones) or syscall tables sharing: >> >> a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t >> (POSIX-compliant) >> b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as >> seen by the user) (POSIX-compliant) >> c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t >> (non-POSIX-compliant) >> >> Option (a) is the easiest from the kernel perspective and has the >> highest chance of not breaking legacy AArch32 applications. >> >> Option (b) is more future looking (beyond 2038) but it introduces a >> third ABI in the kernel (incompatible with both compat and native). >> There is also a risk that legacy applications assume a 32-bit time_t. >> >> Option (c) is pretty much what we currently have in these patches. While >> many syscalls are native LP64, it doesn't fully solve pointers in >> structures shared between user and kernel (ioctl being one of the >> affected areas) >> >> I can't tell how bad the impact of non-POSIX compliance is. If this is >> essential, between (a) and (b) I'm more in favour of (a) as the easiest >> for both kernel and user. If we were to start a new ABI from scratch >> without legacy applications, I would have definitely gone for (b) but >> I'm worried about legacy applications still not fully working with this >> option while adding more maintenance burden in the kernel. >> >> -- >> Catalin >
| |