On Wed, Nov 07, 2018 at 07:45:52AM +0800, Palmer Dabbelt wrote:
> On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@andestech.com wrote:
> > On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
> >> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> >> > On Wed, 31 Oct
On Wed, Nov 07, 2018 at 07:45:52AM +0800, Palmer Dabbelt wrote:
> On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@andestech.com wrote:
> > On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
> >> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> >> > On Wed, 31 Oct
On 11/7/18, Palmer Dabbelt wrote:
> On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote:
>> On 11/5/18, Christoph Hellwig wrote:
>>> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
Many thanks for kinds of comments. I quickly synthesize the comments
and
On 11/7/18, Palmer Dabbelt wrote:
> On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote:
>> On 11/5/18, Christoph Hellwig wrote:
>>> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
Many thanks for kinds of comments. I quickly synthesize the comments
and
On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote:
On 11/5/18, Christoph Hellwig wrote:
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
Many thanks for kinds of comments. I quickly synthesize the comments and
list them as below.
1. The kernel image shall include all
On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@andestech.com wrote:
On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > On Wed, Oct 31, 2018
On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote:
On 11/5/18, Christoph Hellwig wrote:
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
Many thanks for kinds of comments. I quickly synthesize the comments and
list them as below.
1. The kernel image shall include all
On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@andestech.com wrote:
On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > On Wed, Oct 31, 2018
On Mon, Nov 05, 2018 at 02:51:33PM +0100, Arnd Bergmann wrote:
> With the stricter policy you suggest, we'd loose the ability to support
> some extensions that might be common:
>
> - an extension for user space that adds new registers that must be
> saved and restored on a task switch, e.g.
On Mon, Nov 05, 2018 at 02:51:33PM +0100, Arnd Bergmann wrote:
> With the stricter policy you suggest, we'd loose the ability to support
> some extensions that might be common:
>
> - an extension for user space that adds new registers that must be
> saved and restored on a task switch, e.g.
On Mon, Nov 05, 2018 at 09:39:29PM +0200, Nick Kossifidis wrote:
> a) By directly modifying your custom CSRs, it means that we will need
> compiler support in order to compile a kernel with your code in it. This
> will break CI systems and will introduce various issues on testing and
> reviewing
On Mon, Nov 05, 2018 at 09:39:29PM +0200, Nick Kossifidis wrote:
> a) By directly modifying your custom CSRs, it means that we will need
> compiler support in order to compile a kernel with your code in it. This
> will break CI systems and will introduce various issues on testing and
> reviewing
Hello Vincent,
Στις 2018-10-31 12:35, Vincent Chen έγραψε:
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their compiler and CPU. Therefore, each vendor may
be considered a
Hello Vincent,
Στις 2018-10-31 12:35, Vincent Chen έγραψε:
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their compiler and CPU. Therefore, each vendor may
be considered a
On 11/5/18, Christoph Hellwig wrote:
> On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote:
>> > I fundamentally disagree with this… and think it should be the
>> > contrary.
>> >
>> > 1. The kernel shall support no vendor specific instructions whatsoever,
>> > period.
>>
>> I think
On 11/5/18, Christoph Hellwig wrote:
> On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote:
>> > I fundamentally disagree with this… and think it should be the
>> > contrary.
>> >
>> > 1. The kernel shall support no vendor specific instructions whatsoever,
>> > period.
>>
>> I think
On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote:
> > I fundamentally disagree with this… and think it should be the contrary.
> >
> > 1. The kernel shall support no vendor specific instructions whatsoever,
> > period.
>
> I think what was meant above is
>
> 1. If a vendor extension
On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote:
> > I fundamentally disagree with this… and think it should be the contrary.
> >
> > 1. The kernel shall support no vendor specific instructions whatsoever,
> > period.
>
> I think what was meant above is
>
> 1. If a vendor extension
On 11/5/18, Christoph Hellwig wrote:
> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
>> Many thanks for kinds of comments. I quickly synthesize the comments and
>> list them as below.
>> 1. The kernel image shall include all vendor-specific code.
>
> I fundamentally disagree with
On 11/5/18, Christoph Hellwig wrote:
> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
>> Many thanks for kinds of comments. I quickly synthesize the comments and
>> list them as below.
>> 1. The kernel image shall include all vendor-specific code.
>
> I fundamentally disagree with
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
> Many thanks for kinds of comments. I quickly synthesize the comments and
> list them as below.
> 1. The kernel image shall include all vendor-specific code.
I fundamentally disagree with this… and think it should be the contrary.
1.
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote:
> Many thanks for kinds of comments. I quickly synthesize the comments and
> list them as below.
> 1. The kernel image shall include all vendor-specific code.
I fundamentally disagree with this… and think it should be the contrary.
1.
On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> > On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen
> > > wrote:
> > > >
> > > > RISC-V
On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt wrote:
> > On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen
> > > wrote:
> > > >
> > > > RISC-V
On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
> >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> >>> I agree that we need
On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote:
> On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
> >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> >>> I agree that we need
On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> I agree that we need a place for vendor-specific ISA extensions and
> having vendor-specific
On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote:
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> I agree that we need a place for vendor-specific ISA extensions and
> having vendor-specific
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> > I agree that we need a place for vendor-specific ISA extensions and
> > having vendor-specific directories is also good.
>
> The only sensible answer is that we
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote:
> On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> > I agree that we need a place for vendor-specific ISA extensions and
> > having vendor-specific directories is also good.
>
> The only sensible answer is that we
On Wed, Oct 31, 2018 at 10:27 AM Palmer Dabbelt wrote:
>
> On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
> >>
> >> RISC-V permits each vendor to develop respective extension ISA based
> >> on RISC-V standard ISA.
On Wed, Oct 31, 2018 at 10:27 AM Palmer Dabbelt wrote:
>
> On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
> > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
> >>
> >> RISC-V permits each vendor to develop respective extension ISA based
> >> on RISC-V standard ISA.
On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their
On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote:
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> I agree that we need a place for vendor-specific ISA extensions and
> having vendor-specific directories is also good.
The only sensible answer is that we should not allow vendor specific
extensions in the kernel at all. We need to
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote:
> I agree that we need a place for vendor-specific ISA extensions and
> having vendor-specific directories is also good.
The only sensible answer is that we should not allow vendor specific
extensions in the kernel at all. We need to
On 10/31/18, Anup Patel wrote:
> On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen
> wrote:
>>
>> RISC-V permits each vendor to develop respective extension ISA based
>> on RISC-V standard ISA. This means that these vendor-specific features
>> may be compatible to their compiler and CPU. Therefore,
On 10/31/18, Anup Patel wrote:
> On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen
> wrote:
>>
>> RISC-V permits each vendor to develop respective extension ISA based
>> on RISC-V standard ISA. This means that these vendor-specific features
>> may be compatible to their compiler and CPU. Therefore,
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
>
> RISC-V permits each vendor to develop respective extension ISA based
> on RISC-V standard ISA. This means that these vendor-specific features
> may be compatible to their compiler and CPU. Therefore, each vendor may
> be considered a
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen wrote:
>
> RISC-V permits each vendor to develop respective extension ISA based
> on RISC-V standard ISA. This means that these vendor-specific features
> may be compatible to their compiler and CPU. Therefore, each vendor may
> be considered a
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their compiler and CPU. Therefore, each vendor may
be considered a sub-architecture of RISC-V. Currently, vendors do not
have the
RISC-V permits each vendor to develop respective extension ISA based
on RISC-V standard ISA. This means that these vendor-specific features
may be compatible to their compiler and CPU. Therefore, each vendor may
be considered a sub-architecture of RISC-V. Currently, vendors do not
have the
42 matches
Mail list logo
