linux-kernel - Re: [PATCH 0/4] Expose the isa-string via the AT_BASE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <mhng-4b9e3d86-2f0b-47da-8a5d-bd383a0171d6@palmer-ri-x1c9>
Date:   Tue, 02 May 2023 10:15:29 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     philipp.tomsich@...ll.eu
CC:     bjorn@...nel.org, jrtc27@...c27.com, heiko@...ech.de,
        linux-riscv@...ts.infradead.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        kito.cheng@...ive.com, Conor Dooley <conor.dooley@...rochip.com>,
        matthias.bgg@...il.com, heinrich.schuchardt@...onical.com,
        greentime.hu@...ive.com, nick.knight@...ive.com,
        christoph.muellner@...ll.eu,
        Richard Henderson <richard.henderson@...aro.org>,
        Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
        heiko.stuebner@...ll.eu
Subject:     Re: [PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector

On Tue, 02 May 2023 02:13:10 PDT (-0700), philipp.tomsich@...ll.eu wrote:
> On Tue, 2 May 2023 at 09:58, Björn Töpel <bjorn@...nel.org> wrote:
>>
>> Philipp Tomsich <philipp.tomsich@...ll.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.