Messages in this thread | | | Date | Tue, 02 May 2023 10:15:29 -0700 (PDT) | Subject | Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector | From | Palmer Dabbelt <> |
| |
On Tue, 02 May 2023 02:13:10 PDT (-0700), philipp.tomsich@vrull.eu wrote: > On Tue, 2 May 2023 at 09:58, Björn Töpel <bjorn@kernel.org> wrote: >> >> Philipp Tomsich <philipp.tomsich@vrull.eu> writes: >> >> > It is a pity that the current interface was designed without involving >> > RVI (and that I had to ask my team to put together a patch set for >> > further discussion, given that none of the other major vendors in RVI >> > stepped forward). I guarantee that plenty of reviewers would have >> > highlighted that a central registry (even if it is just a kernel >> > header) should be avoided. >> >> Are you claiming that the hwprobe work was not done in the open, but >> secretly merged? That is not only incorrect, but rude to upstream RISC-V >> Linux developers. I suggest you review how you interact with upstream >> kernel work. > > Please don't put words into my mouth... > > I was merely pointing out that there was no engagement by the RVI > member companies (in regard to this mechanism) within RVI, which would > have prevented Jessica's issue. > This would have also helped to address the concerns on vendor-defined > extensions. > > Also who do you refer to when you say "how _you_ interact"? If it is > RVI that you refer to: it doesn't interact with upstream work > directly, as it doesn't own any engineering resources. > RVI provides a forum for member companies to come to an > understanding/design and then have the member companies perform the > work and take it upstream.
I'm not even sure what you're looking for here: if RVI doesn't want to work upstream, then complaining that RVI isn't part of upstream discussions is pretty pointless.
>> Why didn't RVI get involved in the review of the series? The expectation >> cannot be that all open source projects go to RVI, but rather the other >> way around. > > That is exactly the point I was making and which you seem to miss: RVI > does not own any engineering resources and depends solely on its > member companies to project into open source projects. > >> Take a look at commit ea3de9ce8aa2 ("RISC-V: Add a syscall for HW >> probing"). Your team was very much involved in the review. > > I am aware, as I had reviewed and commented on these are well. > And my only request (was and) is that we need to figure out a way to > efficiently deal with vendor-defined extensions.
Maybe you should go talk to you team, then? Handling vendor extensions via hwprobe has been discussed, sounds like you're confused again.
| |