[RISC-V] [tech-tee] [RISC-V] [tech-privileged] Proposed deprecation of N extension
toggle quoted message Show quoted text
While I don't have a strong opinion on N-mode as such, I do worry a bit about being a follower, though not because being a follower is pejorative.
I'd be more concerned that just following may not be possible because of IP issues.
I'd also like to know the reason for the lack of progress on the spec; i
Is it a chicken;egg problem (we need an OS that can demonstrate the value), or
is it that no commerical company sees the value so no one is spending resources to worry about it?
(or is it someone does see the value, and their solution is proprietary...)
Another suggestion would be for an interested group of people to form an official SIG to pursue this area of ideas and innovation. SIGs have more flexibility to explore an area of interest without the burdens of a TG.
Whether under the label of "N" or not is beside the point. It should define its goals and what is/are the problem(s) it is going to tackle (and choose a SIG name). With that, get approval for its creation by the TSC. And then that group can work towards those goals as an organized official part of the RISC-V community. Whether the end result, as an arch extension run through the whole TG process, gets put under the label of "N" or uses a different name is a tertiary issue for when that bridge is crossed.
First and foremost, I apologize to Gernot and to the list. My little rant occurred in a heated moment of frustration with a few things (not related with Gernot or this topic). It was quick venting to what was supposed to be one specific person, and was overly colorful (as such can be). It was of only transient meaning from that moment and its context.
In contrast to what was said, I will assert a non-transient or lasting belief that RISC-V is a community that welcomes all. Everyone comes with different background, different knowledge, and different perspective. Which is a valuable thing for RISC-V. And none of us is perfect. Whether an unintended misstep in this case by me. Or, more generally, a mistake, or an oversight, or a misunderstanding that occasionally occurs for all of us. And we should be understanding of that, since together the "sum can be better than the parts". And with that, I can also say not just for myself but for others of "influence", that there is a conscious view that the goal is not to exert undue influence, but to help guide and to help get all the other work done that getting an idea to a ratified extension entails.
So again, I sincerely apologize for what did not represent my actual views outside of the heat of a certain moment that was not actually centered around Gernot's comments. Gernot, I look forward to your continued participation as part of this community.
TLDR: just tunnel under the "wall of words" to the recommendation below.
This is hardly the hill for any of us to die on, especially by
the hand of our fellow enthusiasts.
The fundamental issue [as I see it] is to remove the designation N from a long standing intended feature.
Andrew and others propose that the time has come to "depreciate" the allocation of this placeholder.
They acknowledge that RISCV.org has done little to develop the original concept under this "N" umbrella.
Further, alternatives to the original concept now appear to provide sufficient functionality to replace their original intent for "N".
Conversely, others had and continue to have high hopes for a
feature or features under the "N" umbrella
that will fulfill what they understood/understand to be the most
hardware [or conceptual, expressive, software translatable] support for [microkernels, rapid I/O handling, platform hardening, etc.]
The fact that development under this "N' placeholder is stalled,
is as much a consequence of its promise as its humble [and spartan] beginnings and
our inadequacies to predictably and spontaneously innovate.
It was much hyped in its early and glory years.
But as it has many promises, the solution that can be developed in our current "extension" methodologies and infrastructure is limited.
We can do two things:
1) Andrew proposed moving out of our current process and abandon "N" as a placeholder.
Use what we have as good enough and allow in ovation to occur outside RISCV.org where we will follow trends as they occur.
2) Relax our current process to be more inclusive. Allow
tentative development under the RISCV umbrella without "strong
governance" [ed. - this euphemism should suffice as a label] by
which TGs and SIGs are encumbered. In this enhanced and receptive
environment self-driven expression and contributions might be able
to flourish and fulfill another vision of those who are enamored
by what "N" promise to them and the world.
Contrary to what Greg attests,
I believe all contributors on this list have a correct understanding of what "N" means, including an understand of the limitations of "the details" [certainly more than squat].
On this I fundamentally disagree:
We definitely need these people, on this list and throughout or organization.
We need visionaries.
Perhaps the need is lower down on the needed list than technophiles, and technologists.
My objection with Greg is not the problem that such people [as he described] present,
but rather the relative value of such persons.
We could argue that luddites are at the the bottom of the "needed list".
But my bottom
rung choice is the intolerant; especially those in positions
of influence and control
Leave "N" as a
placeholder for now.
Continue to pursue other alternatives than originally envisioned, and incorporate that discussion/discovery under this label.
We have observed great interest in advances in this domain [unlike the L and T placeholders].
Perhaps the "Depreciation" proposal and its discussion will stir up the technologists and RISCV regulators to innovate and make this approach fruitful.
On 2021-06-05 10:49 p.m., Greg Favor wrote:
Can I just observe and complain a little that Gernot has been arguing for the N extension - but apparently doesn't know squat about its details. Questioning is fine, but the last thing we need are people strongly arguing for arch features without having an underlying reasonable technical basis or understanding.
Ok, I'm done venting. I've already wasted time on this. :)
On 6 Jun 2021, at 12:22, Jonathan Behrens <behrensj@...> wrote:
OK, if that’s the case then it is of pretty limited use indeed.
Jonathan Behrens <behrensj@...>
toggle quoted message Show quoted text
Wouldn't you also want to isolate different interrupt handlers from each other and from any non-interrupt handler user code running on the system? With the N-extension itself none of that would be possible. In fact, I suspect that a lot of the performance that you might get out of the N-extension specifically comes from running all that code in the same privilege domain.
On Sat, Jun 5, 2021 at 10:08 PM Gernot via lists.riscv.org <gernot.heiser=data61.csiro.au@...> wrote:
The thread model is any attacks on buggy software, and the defence has been known for 45 years: Satzer & Schroder’s Principle of Least Privilege. This means a highly modularised system with almost everything at user level, including device drivers.
|1 - 7 of 7|