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 20
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
list
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 v
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. FPU,
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 yo
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 sub-archi
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 what
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 t
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 perm
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 a
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 dir
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 shou
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. Thi
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 comp
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 sta
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 sub-ar
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 approp
21 matches
Mail list logo
