linux-kernel - Re: [PATCH v10 00/30] Add KVM LoongArch support

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: <e442508c20e8a077892a90b54fdbea302026eacd.camel@xry111.site>
Date:   Mon, 22 May 2023 14:17:24 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     WANG Xuerui <kernel@...0n.name>, maobibo <maobibo@...ngson.cn>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
        Mark Brown <broonie@...nel.org>,
        Alex Deucher <alexander.deucher@....com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Tianrui Zhao <zhaotianrui@...ngson.cn>
Subject: Re: [PATCH v10 00/30] Add KVM LoongArch support

On Mon, 2023-05-22 at 10:37 +0800, WANG Xuerui wrote:
> > Manual is actually one issue, however it does not prevent the review
> > process. There are some drivers for *fruit* devices, I can not find
> > the hw manual also.  With the manual, it helps to review and points
> > out the further and detailed issues.
> 
> There's a *slight* difference: the certain vendor you've mentioned is 
> historically uncooperative in providing the documentation, so outside 
> contributors had to reverse-engineer and document the HW themselves; but 
> in Loongson's case, you *are* the vendor, so you are probably in a 
> position that can make everyone's life easier by at least pushing for 
> the docs release...

And some other differences:

1. *fruit* devices use an ARM64 which is already documented anyway.
2. *fruit* devices are more "popular" and the maintainer can test on it
more easily.  And *fruit* have more fans (esp. more fans with CS/EE
skills, while we have more [expletive deleted] fans :( ) so their
reverse-engineer effort is easier as well.  Yes it may be not fair to
others, but the world is just not fair.
3. *fruit* is really a bad example... When people ask me how to build
Linux From Scratch on *fruit* I just tell them "try to avoid things from
a vendor with no intention to allow you run another OS".

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University