On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:
> This set of patches implements the core Linux support for the AArch64
> (64-bit ARM) architecture.
...
> These patches are also available on this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
On Fri, Jul 06, 2012 at 10:05:41PM +0100, Catalin Marinas wrote:
This set of patches implements the core Linux support for the AArch64
(64-bit ARM) architecture.
...
These patches are also available on this branch:
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
On Sat, 2012-07-07 at 19:27:12 +, Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> >
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64
On Sat, 2012-07-07 at 19:27:12 +, Arnd Bergmann wrote:
On Saturday 07 July 2012, Olof Johansson wrote:
ARM introduced AArch64 as part of the ARMv8 architecture
With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's
On Wed, Jul 18, 2012 at 12:35 PM, Jon Masters wrote:
>
> So we should think with a
> mindset of 2-3 years from now rather than where we were yesterday.
Why do you think aarch64 would be a better name 2-3 years from now?
And why do you think ARM management magically has good taste? They got
the
On 07/18/2012 01:14 PM, Catalin Marinas wrote:
> Debian has different names for the architecture and compiler triplet:
> amd64 with x86_64-linux-gnu, similar for x32. None of these match the
> arch/x86/ Linux directory. Even if there is some confusion initially, it
> will go away in a relatively
Catalin Marinas writes:
> On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
>> El Tue, 17 Jul 2012 22:33:33 -0400
>> Jon Masters escribió:
>> > On 07/17/2012 06:35 PM, Joe Perches wrote:
>> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
>> > >
>> > >> The uname
On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
> El Tue, 17 Jul 2012 22:33:33 -0400
> Jon Masters escribió:
> > On 07/17/2012 06:35 PM, Joe Perches wrote:
> > > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> > >
> > >> The uname will still report
> > >> "aarch64" to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters escribió:
> On 07/17/2012 06:35 PM, Joe Perches wrote:
> > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> >
> >> The uname will still report
> >> "aarch64" to match the compiler triplet and
Hi Jon,
On Wed, Jul 18, 2012 at 06:35:40AM +0100, Jon Masters wrote:
> On 07/06/2012 05:05 PM, Catalin Marinas wrote:
>
> > These patches are also available on this branch:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
> > upstream
>
> What's your general
Hi Jon,
On Wed, Jul 18, 2012 at 06:35:40AM +0100, Jon Masters wrote:
On 07/06/2012 05:05 PM, Catalin Marinas wrote:
These patches are also available on this branch:
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
upstream
What's your general plan for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters jonat...@jonmasters.org escribió:
On 07/17/2012 06:35 PM, Joe Perches wrote:
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
The uname will still report
aarch64 to match the compiler
On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters jonat...@jonmasters.org escribió:
On 07/17/2012 06:35 PM, Joe Perches wrote:
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
The uname will still report
aarch64
Catalin Marinas catalin.mari...@arm.com writes:
On Wed, Jul 18, 2012 at 04:27:12PM +0100, Dennis Gilmore wrote:
El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters jonat...@jonmasters.org escribió:
On 07/17/2012 06:35 PM, Joe Perches wrote:
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas
On 07/18/2012 01:14 PM, Catalin Marinas wrote:
Debian has different names for the architecture and compiler triplet:
amd64 with x86_64-linux-gnu, similar for x32. None of these match the
arch/x86/ Linux directory. Even if there is some confusion initially, it
will go away in a relatively
On Wed, Jul 18, 2012 at 12:35 PM, Jon Masters j...@redhat.com wrote:
So we should think with a
mindset of 2-3 years from now rather than where we were yesterday.
Why do you think aarch64 would be a better name 2-3 years from now?
And why do you think ARM management magically has good taste?
On 07/06/2012 05:05 PM, Catalin Marinas wrote:
> These patches are also available on this branch:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
> upstream
Catalin,
What's your general plan for tracking development with this branch?
Jon.
--
To unsubscribe from
On 07/17/2012 05:50 AM, Alan Cox wrote:
>> Right, I would say that with any CPU core more powerful than this one
>> or with more than a few of these, you will also have trouble coming
>> up with workloads that really require the CPU performance but don't
>> also require a 64 bit virtual address
On 07/17/2012 06:35 PM, Joe Perches wrote:
> On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
>
>> The uname will still report
>> "aarch64" to match the compiler triplet and also avoid confusion of
>> existing 32-bit ARM scripts that simply check for "arm*" in the machine
>> name.
>
>
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> The uname will still report
> "aarch64" to match the compiler triplet and also avoid confusion of
> existing 32-bit ARM scripts that simply check for "arm*" in the machine
> name.
The compiler triplet seems trivial to change.
The other
On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
> On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård wrote:
> >
> > FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> > reasons:
> >
> > - Those are the names people actually use to refer to the architecture
> > -
Hi,
On Mon, Jul 16, 2012 at 01:16:51PM +0100, Pavel Machek wrote:
> > > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > > implementation (while AArch64 is mandatory). If the implementation
> > > > supports it, the most likely scenario for AArch32 at kernel level is
> Right, I would say that with any CPU core more powerful than this one
> or with more than a few of these, you will also have trouble coming
> up with workloads that really require the CPU performance but don't
> also require a 64 bit virtual address space in either user space
> or kernel.
There
On Tuesday 17 July 2012, Christoph Hellwig wrote:
> On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> > Yes, I agree that's the best way to handle this. Compared to other
> > architectures, I think x86 is the only that allows booting either a
> > 32 or 64 bit kernel on the same
On Tuesday 17 July 2012, Jon Masters wrote:
> On 07/16/2012 08:16 AM, Pavel Machek wrote:
>
> >> If an implementation supports AArch32 at EL3 there could be some
> >> physical (or some FPGA config) switch to choose between the two. But
> >> since AArch64 is mandated, I don't see why one would
On Mon, Jul 16, 2012 at 09:24:26AM +0100, Avi Kivity wrote:
> On 07/15/2012 03:16 PM, Catalin Marinas wrote:
> >
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely
On 07/16/2012 04:24 AM, Avi Kivity wrote:
> Can the same kernel image run in both EL1 and EL2? I noticed some .if
> ELs in the assembler files. I guess they could be compiled multiple
> times and the correct version chosen at runtime, or patched up like x86
> does with alternative().
> One of
On 07/16/2012 08:16 AM, Pavel Machek wrote:
>> If an implementation supports AArch32 at EL3 there could be some
>> physical (or some FPGA config) switch to choose between the two. But
>> since AArch64 is mandated, I don't see why one would force AArch32 at
>> EL3 and therefore all lower exception
On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit
On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
Yes, I agree that's the best way to handle this. Compared to other
architectures, I think x86 is the only that allows booting either a
32 or 64 bit kernel on the same system. We used to support 32 bit
kernels on 64 bit PowerMac,
On 07/16/2012 08:16 AM, Pavel Machek wrote:
If an implementation supports AArch32 at EL3 there could be some
physical (or some FPGA config) switch to choose between the two. But
since AArch64 is mandated, I don't see why one would force AArch32 at
EL3 and therefore all lower exception levels
On 07/16/2012 04:24 AM, Avi Kivity wrote:
Can the same kernel image run in both EL1 and EL2? I noticed some .if
ELs in the assembler files. I guess they could be compiled multiple
times and the correct version chosen at runtime, or patched up like x86
does with alternative().
One of the
On Mon, Jul 16, 2012 at 09:24:26AM +0100, Avi Kivity wrote:
On 07/15/2012 03:16 PM, Catalin Marinas wrote:
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for
On Tuesday 17 July 2012, Jon Masters wrote:
On 07/16/2012 08:16 AM, Pavel Machek wrote:
If an implementation supports AArch32 at EL3 there could be some
physical (or some FPGA config) switch to choose between the two. But
since AArch64 is mandated, I don't see why one would force AArch32
On Tuesday 17 July 2012, Christoph Hellwig wrote:
On Sun, Jul 15, 2012 at 07:43:07PM +, Arnd Bergmann wrote:
Yes, I agree that's the best way to handle this. Compared to other
architectures, I think x86 is the only that allows booting either a
32 or 64 bit kernel on the same system. We
Right, I would say that with any CPU core more powerful than this one
or with more than a few of these, you will also have trouble coming
up with workloads that really require the CPU performance but don't
also require a 64 bit virtual address space in either user space
or kernel.
There are
Hi,
On Mon, Jul 16, 2012 at 01:16:51PM +0100, Pavel Machek wrote:
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård m...@mansr.com wrote:
FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
reasons:
- Those are the names people actually use to refer to the architecture
-
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
The uname will still report
aarch64 to match the compiler triplet and also avoid confusion of
existing 32-bit ARM scripts that simply check for arm* in the machine
name.
The compiler triplet seems trivial to change.
The other bit is
On 07/17/2012 06:35 PM, Joe Perches wrote:
On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
The uname will still report
aarch64 to match the compiler triplet and also avoid confusion of
existing 32-bit ARM scripts that simply check for arm* in the machine
name.
The compiler
On 07/17/2012 05:50 AM, Alan Cox wrote:
Right, I would say that with any CPU core more powerful than this one
or with more than a few of these, you will also have trouble coming
up with workloads that really require the CPU performance but don't
also require a 64 bit virtual address space in
On 07/06/2012 05:05 PM, Catalin Marinas wrote:
These patches are also available on this branch:
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
upstream
Catalin,
What's your general plan for tracking development with this branch?
Jon.
--
To unsubscribe from this
Pavel Machek writes:
> Hi!
>
>> The assembly syntax is very reasonable already and not far from what we
>> are used to (see the .S files in my kernel patches). The 64-bit
>> instructions are different and that's specified here (apart from the
>> actual bit encoding):
>>
>>
On Monday 16 July 2012, Pavel Machek wrote:
> > The assembly syntax is very reasonable already and not far from what we
> > are used to (see the .S files in my kernel patches). The 64-bit
> > instructions are different and that's specified here (apart from the
> > actual bit encoding):
> >
> >
Hi!
> The assembly syntax is very reasonable already and not far from what we
> are used to (see the .S files in my kernel patches). The 64-bit
> instructions are different and that's specified here (apart from the
> actual bit encoding):
>
>
Hi!
> > > The AArch32 execution mode is optional, so it depends on the actual CPU
> > > implementation (while AArch64 is mandatory). If the implementation
> > > supports it, the most likely scenario for AArch32 at kernel level is in
> > > virtual machines or the secure OS. I'll explain below why.
On Sun, Jul 15, 2012 at 9:43 PM, Arnd Bergmann wrote:
> Yes, I agree that's the best way to handle this. Compared to other
> architectures, I think x86 is the only that allows booting either a
> 32 or 64 bit kernel on the same system. We used to support 32 bit
> kernels on 64 bit PowerMac, but
On 07/15/2012 03:16 PM, Catalin Marinas wrote:
>
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the
On 07/15/2012 03:16 PM, Catalin Marinas wrote:
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
virtual machines or the secure OS.
On Sun, Jul 15, 2012 at 9:43 PM, Arnd Bergmann a...@arndb.de wrote:
Yes, I agree that's the best way to handle this. Compared to other
architectures, I think x86 is the only that allows booting either a
32 or 64 bit kernel on the same system. We used to support 32 bit
kernels on 64 bit
Hi!
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
virtual machines or the secure OS. I'll explain below why.
The
Hi!
The assembly syntax is very reasonable already and not far from what we
are used to (see the .S files in my kernel patches). The 64-bit
instructions are different and that's specified here (apart from the
actual bit encoding):
On Monday 16 July 2012, Pavel Machek wrote:
The assembly syntax is very reasonable already and not far from what we
are used to (see the .S files in my kernel patches). The 64-bit
instructions are different and that's specified here (apart from the
actual bit encoding):
Pavel Machek pa...@ucw.cz writes:
Hi!
The assembly syntax is very reasonable already and not far from what we
are used to (see the .S files in my kernel patches). The 64-bit
instructions are different and that's specified here (apart from the
actual bit encoding):
On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård wrote:
>
> FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> reasons:
>
> - Those are the names people actually use to refer to the architecture
> - They are more descriptive.
> - I think the official name is rather silly.
Catalin Marinas writes:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
>> * Arnd Bergmann wrote:
>> > On Saturday 07 July 2012, Olof Johansson wrote:
>> > > > ARM introduced AArch64 as part of the ARMv8 architecture
>> > >
>> > > With the risk of bikeshedding here, but I find
On Sun, Jul 15, 2012 at 08:43:07PM +0100, Arnd Bergmann wrote:
> On Sunday 15 July 2012, Catalin Marinas wrote:
> > The AArch32 execution mode is optional, so it depends on the actual CPU
> > implementation (while AArch64 is mandatory). If the implementation
> > supports it, the most likely
On Sunday 15 July 2012, Catalin Marinas wrote:
> The AArch32 execution mode is optional, so it depends on the actual CPU
> implementation (while AArch64 is mandatory). If the implementation
> supports it, the most likely scenario for AArch32 at kernel level is in
> virtual machines or the secure
On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
> > > > Agreed. It's clear from the code that it started out as a copy
> > > > of the 32 bit ARM code base, which I think was a mistake, but
> > > > it has also moved on since then and many areas of the 64 bit
> > > > code are now
On Sat, Jul 14, 2012 at 10:35:05AM +0100, Pavel Machek wrote:
> On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> > On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > > Catalin Marinas writes:
> > > > Compilation requires a new aarch64-none-linux-gnu-
> > > > toolchain
On Sat, Jul 14, 2012 at 10:35:05AM +0100, Pavel Machek wrote:
On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
Catalin Marinas writes:
Compilation requires a new aarch64-none-linux-gnu-
toolchain
On Sat, Jul 14, 2012 at 10:30:32AM +0100, Pavel Machek wrote:
Agreed. It's clear from the code that it started out as a copy
of the 32 bit ARM code base, which I think was a mistake, but
it has also moved on since then and many areas of the 64 bit
code are now much cleaner
On Sunday 15 July 2012, Catalin Marinas wrote:
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for AArch32 at kernel level is in
virtual machines or the secure OS.
On Sun, Jul 15, 2012 at 08:43:07PM +0100, Arnd Bergmann wrote:
On Sunday 15 July 2012, Catalin Marinas wrote:
The AArch32 execution mode is optional, so it depends on the actual CPU
implementation (while AArch64 is mandatory). If the implementation
supports it, the most likely scenario for
Catalin Marinas catalin.mari...@arm.com writes:
On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
* Arnd Bergmann a...@arndb.de wrote:
On Saturday 07 July 2012, Olof Johansson wrote:
ARM introduced AArch64 as part of the ARMv8 architecture
With the risk of bikeshedding
On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård m...@mansr.com wrote:
FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
reasons:
- Those are the names people actually use to refer to the architecture
- They are more descriptive.
- I think the official name is rather
On 07/10/2012 04:16 PM, Alexander Holler wrote:
> And it isn't so that the name will have to be used that seldom, at least
> every distribution would need to use it to name the flavour, like e.g.
> "Fedora AArch64hf" or "Debian AArch64".
The good news is we won't need an "hf" release because
On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
> On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> > Catalin Marinas writes:
> > > Compilation requires a new aarch64-none-linux-gnu-
> > > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
> >
> > Where
Hi!
> > > > With the risk of bikeshedding here, but I find the name awkward. How
> > > > about just naming the arch port arm64 instead? It's considerably more
> > > > descriptive in the context of the kernel. For reference, we didn't
> > > > name ppc64, nor powerpc, after what the IBM/power.org
Hi!
With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's considerably more
descriptive in the context of the kernel. For reference, we didn't
name ppc64, nor powerpc, after what the IBM/power.org marketing people
On Tue 2012-07-10 11:12:23, Catalin Marinas wrote:
On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
Catalin Marinas writes:
Compilation requires a new aarch64-none-linux-gnu-
toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
Where are the
On 07/10/2012 04:16 PM, Alexander Holler wrote:
And it isn't so that the name will have to be used that seldom, at least
every distribution would need to use it to name the flavour, like e.g.
Fedora AArch64hf or Debian AArch64.
The good news is we won't need an hf release because we're all
On Wed, 11 Jul 2012 11:53:35 +0100, Catalin Marinas
wrote:
> Hi Rusty,
Hi Catalin,
This is fun!
> On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> > I know it's a crazy idea, but why don't we try some actual analysis?
>
> This kind of analysis is not relevant. It's
On Wed, 11 Jul 2012 11:53:35 +0100, Catalin Marinas catalin.mari...@arm.com
wrote:
Hi Rusty,
Hi Catalin,
This is fun!
On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
I know it's a crazy idea, but why don't we try some actual analysis?
This kind of analysis is not
> What if they add 64-bit ARM support to arch/x86? AFAIK some of the
> machines are going to be basically PCs, including legacy I/O, ACPI
> and UEFI, so they are much closer to that than they are to anything
> in arch/arm. The instruction set of course is different, but you
> already said that
Hi Rusty,
On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
> On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann wrote:
> > On Tuesday 10 July 2012, Alan Cox wrote:
> > > > In the AArch32 kernel port many implementation decisions newer
> > > > architectures were made in a way that
On Tue, Jul 10, 2012 at 10:44:29PM +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> > Do you *really* think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ +
* Arnd Bergmann wrote:
> > Do you really think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ + drivers/ or the
> > highway?
>
> Yes.
Straight answer ;-)
> If you're curious, please have a look at
* Arnd Bergmann a...@arndb.de wrote:
Do you really think that all of the 32-bit ARM code should
essentially be thrown away when going to 64-bit ARM, that
patches can only touch arch/arm64/ + drivers/ or the
highway?
Yes.
Straight answer ;-)
If you're curious, please have a look
On Tue, Jul 10, 2012 at 10:44:29PM +0100, Catalin Marinas wrote:
On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
Do you *really* think that all of the 32-bit ARM code should
essentially be thrown away when going to 64-bit ARM, that
patches can only touch arch/arm64/ +
Hi Rusty,
On Wed, Jul 11, 2012 at 06:26:49AM +0100, Rusty Russell wrote:
On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 10 July 2012, Alan Cox wrote:
In the AArch32 kernel port many implementation decisions newer
architectures were made in a way that
What if they add 64-bit ARM support to arch/x86? AFAIK some of the
machines are going to be basically PCs, including legacy I/O, ACPI
and UEFI, so they are much closer to that than they are to anything
in arch/arm. The instruction set of course is different, but you
already said that this
On Tue, 10 Jul 2012 16:52:18 +, Arnd Bergmann wrote:
> On Tuesday 10 July 2012, Alan Cox wrote:
> > > In the AArch32 kernel port many implementation decisions newer
> > > architectures were made in a way that preserves backwards compatibility
> > > to over 15 years ago (and for good reasons,
Once upon a time, Catalin Marinas said:
>Changing the arch/ dir name is easy at this point. My preference is for
>consistency with the official name (that cannot be changed) and the gcc
>triplet.
What ARM Ltd. says is the "official" name isn't necessarily what the
rest of the world will call
On Tue, Jul 10, 2012 at 10:19:38PM +0100, Arnd Bergmann wrote:
> On Tuesday 10 July 2012, Ingo Molnar wrote:
> > Do you really think that all of the 32-bit ARM code should
> > essentially be thrown away when going to 64-bit ARM, that
> > patches can only touch arch/arm64/ + drivers/ or the
(just replying to a couple of points now, I'll follow up tomorrow)
On Tue, Jul 10, 2012 at 09:35:27PM +0100, Ingo Molnar wrote:
> Do you *really* think that all of the 32-bit ARM code should
> essentially be thrown away when going to 64-bit ARM, that
> patches can only touch arch/arm64/ +
On Tuesday 10 July 2012, Ingo Molnar wrote:
> So are you really convinced that the colorful ARM SoC world is
> not going to go 64-bit and will all unify behind a platform, and
> that we can actually force this process by not accepting
> non-generic patches? Is such a platform design being
* Arnd Bergmann wrote:
> > What plans to other maintainers and board vendors have ? Any
> > design choice has to cope with these happening if a third
> > party goes and does it.
>
> It is slightly worrying to have multiple SoC vendors working
> on their own platform support. There are a few
Am 10.07.2012 19:14, schrieb Joe Perches:
On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:
On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
* Arnd Bergmann wrote:
On Saturday 07 July 2012, Olof Johansson wrote:
ARM introduced AArch64 as part of the ARMv8 architecture
On Tue, Jul 10, 2012 at 8:01 PM, Jan Ceuleers wrote:
> Perhaps it's a typo, and was meant to be AArgh64 :-)
Still a much better name than aarch64.
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 07/10/2012 07:14 PM, Joe Perches wrote:
> Count me as one of the 1000s that think it's a poor name choice.
> I think it's a poor name for marketing purposes too.
>
> Best of luck with whatever is used.
Perhaps it's a typo, and was meant to be AArgh64 :-)
--
To unsubscribe from this list: send
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Tue, 10 Jul 2012 11:10:18 +0100
Catalin Marinas escribió:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of
On Tue, 2012-07-10 at 11:10 +0100, Catalin Marinas wrote:
> On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> > * Arnd Bergmann wrote:
> > > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > > >
> > > > With the
On Tue, Jul 10, 2012 at 04:33:58PM +0100, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> > use). But
On Tuesday 10 July 2012, Alan Cox wrote:
> > In the AArch32 kernel port many implementation decisions newer
> > architectures were made in a way that preserves backwards compatibility
> > to over 15 years ago (and for good reasons, ARMv4 hardware is still in
> > use). But keeping the same
> In the AArch32 kernel port many implementation decisions newer
> architectures were made in a way that preserves backwards compatibility
> to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in
> use). But keeping the same decisions in AArch64 is wrong.
Same argument as x86-32
On Tue, Jul 10, 2012 at 08:10:23AM +0100, Ingo Molnar wrote:
> * Arnd Bergmann wrote:
> > On Saturday 07 July 2012, Olof Johansson wrote:
> > > > ARM introduced AArch64 as part of the ARMv8 architecture
> > >
> > > With the risk of bikeshedding here, but I find the name awkward. How
> > > about
On Sat, Jul 07, 2012 at 10:30:58AM +0100, Mikael Pettersson wrote:
> Catalin Marinas writes:
> > Compilation requires a new aarch64-none-linux-gnu-
> > toolchain (http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01694.html).
>
> Where are the corresponding binutils patches? Without those it's
>
* Arnd Bergmann wrote:
> On Saturday 07 July 2012, Olof Johansson wrote:
>
> > > ARM introduced AArch64 as part of the ARMv8 architecture
> >
> > With the risk of bikeshedding here, but I find the name awkward. How
> > about just naming the arch port arm64 instead? It's considerably more
> >
* Arnd Bergmann a...@arndb.de wrote:
On Saturday 07 July 2012, Olof Johansson wrote:
ARM introduced AArch64 as part of the ARMv8 architecture
With the risk of bikeshedding here, but I find the name awkward. How
about just naming the arch port arm64 instead? It's considerably more
1 - 100 of 188 matches
Mail list logo
