Re: [committed] RISC-V: XVentanaCondops support

[Palmer Dabbelt <palmer@dabbelt.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5034 bytes --]

On Fri, 28 Apr 2023 11:43:50 PDT (-0700), jeffreyalaw@gmail.com wrote:
>
>
> On 4/26/23 15:42, Palmer Dabbelt wrote:
>> We had the various RISC-V port maintainers and long-term contributors in
>> FSF toolchain land (ie, binutils/GCC/glibc) agree on something posted to
>> the mailing list.
>>
>> Philipp and I certainly talked about it, but there's no private
>> agreements or anything like that -- it's just what we discuss on the
>> mailing lists.  Unfortunately he has along history of misrepresenting
>> things, but that's really why we're so careful about making sure that
>> all the decisions are talked about on the lists.
> I wasn't implying any private communications.  It was more a reflection
> that you and Philipp seemed to be the principals in the overall discussion.

That's probably how it looks publicly, but it's not how it happens in 
practice.  Essentially we have an off-list discussion with the various 
maintainers/contributors who do RISC-V stuff, and then go post the 
result of that on the list.

I actually don't like doing things that way, I'd prefer to do things in
public.  That's how we used to do it, but we ended up with so much
trouble from the folks at the RISC-V foundation that we stopped.

I'm not opposed to trying to have the discussions in public again,
though.  It doesn't really impact me personally because I take all the
heat for posting these publicly, so it's really up to everyone else.

> My recollection from the discussion back in Nov/Dec was that the only
> thing we were still waiting on for xventanacondops to move forward was
> an announcement of the chip.  My understanding was the chip didn't need
> to actually be available yet.  Maybe I'm mis-remembering, and if so,
> I've got no problem pulling this out.
>
> Perhaps the requirements should be posted somewhere so that gcc,
> binutils, gdb, glibc, etc can all refer to and follow the same
> procedures for accepting vendor specific bits.

There's a thread here: 
https://inbox.sourceware.org/gcc-patches/mhng-289aa2f5-86f4-4cdb-bed5-1ce130ddc841@palmer-mbp2014/

It doesn't look like we came to an agreement, though.  The only concrete 
place we wrote things down was in Linux: 
<https://docs.kernel.org/riscv/patch-acceptance.html>.  That's stricter 
than the toolchain side of things, though, as it specifically requires 
vendors to have a history of shipping before we take 
pre-publicly-availiable hardware.

>> The idea was to have some sort of timeline around availability of the
>> hardware -- essentially the goal is to avoid being stuck supporting
>> stuff that doesn't actually make it out of the lab.  I can't find
>> anything that actually says that, but then also I'm pretty much allergic
>> to chip company marketing material these days so I sort of stay out of
>> it ;)
> I don't recall a timeline in the requirements.  But again, it's been
> months since we kicked this stuff around.  I can't speak to timelines
> other than "we're waiting on hardware to start bring-up".

IIRC the core of it was this "we'll take the support, but if the 
hardware doesn't show up on whatever timeline was announced then we'll 
aggressively remove it".

That said, I can't find anything.

>> The best I've been able to find is this "Veyron V1 is Highest
>> Performance RISC-V Processor running at 3.6GHz in 5nm" [1].  The
>> big-ticket ones like an SDK and dev board don't seem to exist anywhere
>> outside of press releases, though (there's a github [2], but no SDK).
> I don't think we've released our SDK to anyone except partners.  So no
> surprise you can't find an SDK :)
>
>>
>> I know it's kind of pedantic, but we've had a lot of issues in the past
>> with RISC-V folks making stuff up and trying to push around upstream.
>> I'm not saying you're doing that, you've been around long enough that if
>> you say you have a chip I believe you.  The goal is to be fair to
>> everyone, though -- essentially the same as what happened for the GCC
>> patches.
> No worries.  As I've noted in the past, I'm keenly aware of the desire
> to avoid even the appearance of unfairness or someone taking advantage
> of their position in the communities.  It's something that's been
> important to me personally for decades in the GCC space, so you don't
> ever have to worry about explaining it to me or offending me by being
> pedantic in this space.
>
> I'm not going to lose any sleep if we need to delay bits for veyron-v1,
> I just want to make sure we have an agreed upon process so that we know
> when things can go forward across the various tools.  I'm actually more
> concerned about this for gcc than binutils/gdb as we have scheduler
> models, costing models, etc that I'd like to get submitted.  I've held
> off doing that for the duration of the gcc-13 cycle, but very much want
> to see those things move forward in the gcc-14 cycle.
>
> So in summary, let's get the agreement/policy posted in a easily found
> location.  I'll suggest the GCC wiki, but I'm certainly not wed to that
> idea.

I'm fine with that.