Re: [sw-dev] SBI extension proposal v2

[Luke Kenneth Casson Leighton <lkcl@lkcl.net>]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Wed, Jan 30, 2019 at 12:50 AM Bruce Hoult <brucehoult@sifive.com> wrote:
>
> On Tue, Jan 29, 2019 at 4:06 PM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Tue, Jan 29, 2019 at 11:26 PM Palmer Dabbelt <palmer@sifive.com> wrote:
> >
> > > Yep, and the hope here is that we can build something that allows everyone to implement their systems within the same framework.  With any luck we'll be able to build a platform specification that allows both of these systems to exist -- essentially "boot Linux into M-mode" or "boot Linux into S-mode".  It'll be work to make sure the spec can work for everyone, but that's part of the way to get a good spec.
> >
> >  ... and how is that to be achieved if the RISC-V Foundation
> > pathologically insists on secretive closed-doors discussions when it
> > comes to RISC-V specifications?
> >
> >  it's time for the RISC-V Foundation to recognise that the ITU-style
> > closed doors practice is damaging the ecosystem by preventing people
> > from contributing.
>
> There needs to be some slight barrier to entry, some commitment
> needed, otherwise the process has a real danger of simply being
> flooded by concern-trolls and time-wasters and never completing.

 it's a legitimate concern, that i've witnessed from a couple of
"open" projects.  one of them was the mozilla "B2G" initiative, which
was flooded with top-postings of wannabe security "contributors" with
zero actual security experience, that drowned out legitimate security
analysis from "outsiders".

 it turned out in that particular case that it was well-known (for
over a decade) that there was a "core" team, who had absolutely no
intention whatsoever of listening to "outsider" constructive feedback,
regardless of consequences (including severe security design flaws).

 the "public discussion" was therefore preettty much pointless, and a
political sop.  it served a purpose of providing a bike-shed magnet so
that the "real" discussion by the "core team" could take place in
secret.

 ... guess what?  the project failed.

> Designing things by discussion and consensus rather than simply having
> a completed spec handed down from some expert is already
> time-consuming enough.

 it is... and that's just something that has to be accepted.  in open
(unregulated) discussions, what i find tends to happen is as follows:

 * time-wasters - those people not actually committed to the *genuine*
process of achieving the defined goal - tend to fall away through a
process of attrition.  over time, they simply don't get traction
(attention) and, through lack of long-term committment, they simply...
give up.

 * a *small* number of pathologically / psychologically disturbed
people, after a *long* and very very patient repetition of
non-confrontational hints from a large enough group, *eventually* get
the message and also give up.

which leaves behind a core of dedicated people who are *actually*
committed to the goal.  where it gets complicated is if the goal has
not been clearly defined, there is conflict and confusion,
proportional to the number of contributors.

the bottom line is: people have to be *really* dedicated to want to
contribute in this extremely technical field.  those people that are
not so motivated and not sufficiently technically competent become,
over time, quite easy to empirically identify.

l.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv