On Monday 04 May 2015 12:29:52 Arnd Bergmann wrote:
>
> For 'struct stat', I ended up introducing a new structure on arm32 that
> matches the layout of arm64 (and I did the same for all other 32-bit
> architectures that have a 64-bit counterpart). This means we can share
> the same system calls be
On Monday 04 May 2015 12:32:30 Dr. Philipp Tomsich wrote:
> Arnd,
>
> Where can I pull this prototype implementation from?
> As we are working on getting a final ILP32 change-set ready, I’d like to make
> sure that we base this on the latest consensus for new ILP32 ABIs on 64bit
> machines.
>
I
Arnd,
Where can I pull this prototype implementation from?
As we are working on getting a final ILP32 change-set ready, I’d like to make
sure that we base this on the latest consensus for new ILP32 ABIs on 64bit
machines.
Thanks,
Philipp.
> On 04 May 2015, at 12:29, Arnd Bergmann wrote:
>
> On
On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote:
> Given Catalin's comments from yesterday, I think we can just fix the
> definitions of 'struct stat64' for asm-generic to make it have the same
> layout as the 64-bit version of 'struct stat', and use that for aarch64-ilp32.
>
> Similarly fo
On Monday 20 April 2015 16:56:00 Catalin Marinas wrote:
> On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> > On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > | typedef unsigned short __kernel_mo
On Fri, Apr 17, 2015 at 05:49:44PM +0200, Arnd Bergmann wrote:
> On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> > On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > > g) create a new ABI that does things in exactly the way that we
> > > would use as the native sysc
On 2015/4/17 21:17, Arnd Bergmann wrote:
On Friday 17 April 2015 10:01:56 Catalin Marinas wrote:
On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote:
On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
There are
On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote:
> More comments below.
>
> > On 17 Apr 2015, at 16:46, Catalin Marinas wrote:
> >
> > Even in this case, we could enable AArch32 compat knowing that ioctls
> > wouldn't work. If this is important, we can add an option to enable
> > ioct
On Friday 17 April 2015 15:46:57 Catalin Marinas wrote:
> On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> > - If we do not use the exact data structures that we have on aarch32,
> > then I think we should make aarch32 emulation and aarch64-ilp32
> > emulation mutually exclusive
More comments below.
> On 17 Apr 2015, at 16:46, Catalin Marinas wrote:
>
> Even in this case, we could enable AArch32 compat knowing that ioctls
> wouldn't work. If this is important, we can add an option to enable
> ioctl support for ILP32 and re-target the asm/compat.h definitions.
>
>> g)
Even more options below ;). I'll add mine.
On Fri, Apr 17, 2015 at 02:17:32PM +0100, Arnd Bergmann wrote:
> Here is my current line of thinking:
>
> - Using all the aarch32 data structures would be the easiest way, then
> we could use the side of asm-generic/unistd.h and everything should
> w
Am 17.04.2015 um 15:17 schrieb Arnd Bergmann :
> On Friday 17 April 2015 10:01:56 Catalin Marinas wrote:
> On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote:
> On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
> On Thu, Apr 16, 2015 at 11:33:49AM +00
On Friday 17 April 2015 10:01:56 Catalin Marinas wrote:
> On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote:
> > On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
> > > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> > > > There are only a few places where long
On Thu, Apr 16, 2015 at 05:21:30PM +0200, Arnd Bergmann wrote:
> On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
> > On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> > > There are only a few places where long should be 32bit rather than
> > > 64bit. The non-time_t field o
On Thursday 16 April 2015 14:31:34 Catalin Marinas wrote:
> On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
> > wrote:
> > > Just for the record (and to avoid anyone wasting their time on what’s
> > > available
> > > today): we
On Thu, Apr 16, 2015 at 01:19:14PM +0200, Dr. Philipp Tomsich 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 o
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
> On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
> 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
> > p
> On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
> 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 o
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 wil
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 proc
On 15.04.15 19:22, Catalin Marinas wrote:
> On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote:
>> On 15 Apr 2015, at 17:38, Catalin Marinas wrote:
>>> On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
>>
On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 17:38, Catalin Marinas wrote:
> > On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
> >> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
> >>> On Wed, Apr 15, 2015 at 11:18:06AM +0200,
> On 15 Apr 2015, at 17:38, Catalin Marinas wrote:
>
> On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
>> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
>>> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
We’ve run full systems (built from bui
On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 13:22, Catalin Marinas wrote:
> > I think you are right. I was more thinking of those routed directly to
> > the native (non-compat) syscalls. We would need to make sure the return
> > value (X0 being the onl
On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
> > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
> > > We’ve run full systems (built from buildroot) consisting of ILP32 binaries
> > > only (ok… admit
On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:
> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
> > On 15 Apr 2015, at 00:28, Arnd Bergmann wrote:
> > > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
> > >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd
On Tuesday 14 April 2015 17:55:00 Catalin Marinas wrote:
> On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
> > So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
> > language. Any program that assumes that tv_nsec is sizeof(long) would be
> > correct and
On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote:
>
> > On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
> >
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and
> >> ioctls:
> >> we have many drivers that today use ioctls with data structures derived
> >> fro
On Tuesday 14 April 2015 16:54:22 Dr. Philipp Tomsich wrote:
> On 14 Apr 2015, at 16:07, Arnd Bergmann wrote:
> >
> > I don't understand what you mean here, please elaborate. Why would an ABI
> > that works
> > on aarch32 be wrong on aarch64-ilp32 user space when you are using the same
> > hea
On Tue, Apr 14, 2015 at 05:44:07PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote:
> > On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> > > d) don't use the asm-generic/unistd.h table for aarch64-ilp32 at all, but
> > > instead
> > >reuse
Catalin,
even though this may now be moot, as we’ll out a 32bit time_t on ILP32 (making
it
very similar to n32 on MIPS), here’s the the info on what would be affected by
changing timespec.
Below is a (hopefully) full list of system calls, helper functions and exposed
data
structures (with som
On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
> On 15 Apr 2015, at 00:28, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
> >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
> >>> For completeness, there is yet another option
> On 15 Apr 2015, at 00:28, Arnd Bergmann wrote:
>
> On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
>> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
>>> For completeness, there is yet another option, which would be to use the
>>> exact system call table from arm64 and
On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
> > For completeness, there is yet another option, which would be to use the
> > exact system call table from arm64 and do all the emulation in user space
> > rather than the ke
On Tue, Apr 14, 2015 at 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
> > On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
> >> I mainly want to avoid accidentally creating new ABIs for syscalls and
> >> ioctls:
> >> we have many drivers that today use ioctls with data structures derived
> >> fro
On Tuesday 14 April 2015 15:47:02 Catalin Marinas wrote:
> On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> > > After getting a good night’s sleep, the “reuse the existing system call
> > > table” comment
> > > makes
> On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
>
>> I mainly want to avoid accidentally creating new ABIs for syscalls and
>> ioctls:
>> we have many drivers that today use ioctls with data structures derived from
>> '__kernel_ulong_t' in some form, often by including a timespec or time_t i
On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote:
> For completeness, there is yet another option, which would be to use the
> exact system call table from arm64 and do all the emulation in user space
> rather than the kernel. This would however be the least compatible with
> existing
On Tue, Apr 14, 2015 at 11:51:54AM +, Pinski, Andrew wrote:
> > On Apr 14, 2015, at 4:15 AM, Arnd Bergmann wrote:
> > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
> >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
> >>> There are multiple ways of doing this:
> >>>
> >>> a) se
On Tue, Apr 14, 2015 at 12:08:11PM +0200, Arnd Bergmann wrote:
> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> > After getting a good night’s sleep, the “reuse the existing system call
> > table” comment
> > makes a little more sense as I construe it as having just one merged sys
On Tuesday 14 April 2015 13:50:21 Dr. Philipp Tomsich wrote:
>
> > On 14 Apr 2015, at 13:14, Arnd Bergmann wrote:
> >
> > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
> >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
> >>>
> On Tuesday 14 April 2015 11:33:13 Dr. Philipp
On Tue, Apr 14, 2015 at 10:45:43AM +, Pinski, Andrew wrote:
> Also about time_t, my original patch had used 32bit but was asked to
> change it to the 64bit one. So now I am upset this being asked again
> to change it back.
At the time, we were not aware of plans to fix existing 32-bit
architec
> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
>
>> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
>> Arnd,
>>
>> After getting a good night’s sleep, the “reuse the existing system call
>> table” comment
>> makes a little more sense as I construe it as having just one me
> On Apr 14, 2015, at 4:15 AM, Arnd Bergmann wrote:
>
> On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
>>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
>>>
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
Arnd,
After getting a good night’s sle
> On 14 Apr 2015, at 13:14, Arnd Bergmann wrote:
>
> On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
>>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
>>>
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
Arnd,
After getting a good night’s sleep, th
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
> > On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote:
> >
> >> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> >> Arnd,
> >>
> >> After getting a good night’s sleep, the “reuse the existing system call
> >> table” comment
>
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
> Arnd,
>
> After getting a good night’s sleep, the “reuse the existing system call
> table” comment
> makes a little more sense as I construe it as having just one merged system
> call table
> for both LP64 and ILP32 and handling the
On Tuesday 14 April 2015 00:58:59 Dr. Philipp Tomsich wrote:
> Arnd,
>
> > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance
> > burden, and we don't want to do that just because someone thinks it's a cute
> > hack or because it might add a few percent in performance of som
Arnd,
> 1. Adding a whole new ABI to the kernel is adding a long-term maintenance
> burden, and we don't want to do that just because someone thinks it's a cute
> hack or because it might add a few percent in performance of some low-level
> benchmark. Please describe in the cover-letter for the pa
On Monday 13 April 2015 21:44:10 Philipp Tomsich wrote:
> If anybody wants to rerun LTP, let me know, so I can provide a
> buildroot-generated rootfs-image via FTP.
>
> The key differences from earlier changesets are:
> * updated to 4.0
> * fixes for functions using 'struct msgbuf' (using compat
50 matches
Mail list logo
