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
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
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 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
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 for
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 a...@arndb.de
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
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
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
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
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
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_mode_t;
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 syscall
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
> >
On Friday 17 April 2015 17:15:46 Dr. Philipp Tomsich wrote:
More comments below.
On 17 Apr 2015, at 16:46, Catalin Marinas catalin.mari...@arm.com 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
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
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
>
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
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
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
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 of
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
work
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 should
Am 17.04.2015 um 15:17 schrieb Arnd Bergmann a...@arndb.de:
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,
More comments below.
On 17 Apr 2015, at 16:46, Catalin Marinas catalin.mari...@arm.com 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
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, and
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):
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
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
> >
> 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
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
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
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
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
On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
philipp.toms...@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)
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
philipp.toms...@theobroma-systems.com wrote:
Just for the record (and to avoid anyone wasting their time on what’s
On Thu, Apr 16, 2015 at 11:33:49AM +, Pinski, Andrew wrote:
On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich
philipp.toms...@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)
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 on (b)
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
> 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
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
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…
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
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
> >>
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
> >
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
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
> 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:54:22 Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 16:07, Arnd Bergmann a...@arndb.de 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
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 it
On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com 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
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 a...@arndb.de wrote:
On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote:
On Tue, Apr 14, 2015 at 04:07:36PM +0200,
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… admittedly
On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote:
On 15 Apr 2015, at 13:22, Catalin Marinas catalin.mari...@arm.com 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
On 15 Apr 2015, at 17:38, Catalin Marinas catalin.mari...@arm.com 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
On Wed, Apr 15, 2015 at 07:01:23PM +0200, Dr. Philipp Tomsich wrote:
On 15 Apr 2015, at 17:38, Catalin Marinas catalin.mari...@arm.com 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
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 catalin.mari...@arm.com wrote:
On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:
On Wednesday 15 April 2015 11:01:54 Catalin
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
On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:
On 15 Apr 2015, at 00:28, Arnd Bergmann a...@arndb.de 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
On 15 Apr 2015, at 00:28, Arnd Bergmann a...@arndb.de 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
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 the table
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
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
> >>
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
> > >
> 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
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)
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
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
> 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
> 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
> 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,
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
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
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 some
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de 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
On 14 Apr 2015, at 13:14, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
Arnd,
After getting a good night’s sleep,
On Apr 14, 2015, at 4:15 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote:
Arnd,
After getting a good night’s
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 10:45:43 Pinski, Andrew wrote:
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de 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 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
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 05:29:36PM +0200, Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com 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
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 system
On Tue, Apr 14, 2015 at 11:51:54AM +, Pinski, Andrew wrote:
On Apr 14, 2015, at 4:15 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de wrote:
There are multiple ways of doing this:
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 a little
On 14 Apr 2015, at 16:47, Catalin Marinas catalin.mari...@arm.com 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
On Tuesday 14 April 2015 13:50:21 Dr. Philipp Tomsich wrote:
On 14 Apr 2015, at 13:14, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote:
On Apr 14, 2015, at 3:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 April 2015 11:33:13 Dr.
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 kernel.
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
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
This is an updated version of Andrew Pinski's ILP32 patch-series for ARM64
(see https://lkml.org/lkml/2014/9/3/704) which merges some changes from our
implementation of ILP32 with his.
I made sure to have Andrew as an author, wherever no significant
changes to his patches occurred and updated the
This is an updated version of Andrew Pinski's ILP32 patch-series for ARM64
(see https://lkml.org/lkml/2014/9/3/704) which merges some changes from our
implementation of ILP32 with his.
I made sure to have Andrew as an author, wherever no significant
changes to his patches occurred and updated the
1 - 100 of 102 matches
Mail list logo
