[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [patches] Re: [PULL] RISC-V QEMU Port Submission
From: |
Peter Maydell |
Subject: |
Re: [Qemu-devel] [patches] Re: [PULL] RISC-V QEMU Port Submission |
Date: |
Wed, 28 Feb 2018 11:53:01 +0000 |
On 28 February 2018 at 00:09, Michael Clark <address@hidden> wrote:
> I've just talked to SiFive about this. They have agreed that we can remove
> the sifive_e300 and sifive_u500 boards from the patch series that we are
> going to submit upstream again later this week or early next week. These
> machines and their devices are pretty easy for us to maintain in the riscv
> or a sifive repo. This trims the number of machines from 5 to 3 and lets us
> remove the SiFiveUART and SiFivePRCI from the next patch series we are
> going to submit. e.g. v8
Models of boards which people actively want and are using are fine
(though indeed you can save them for a later round of patches if you
like). And it sounds like the 1.9.1 stuff is genuinely wanted, so
thanks for the clarification there. What I want to avoid is boards
going into QEMU just because you happened to have them already. Once
a board model goes into QEMU it's a commitment to supporting it for
the long term, and getting rid of it again is hard.
> However I'm inclined to leave it as it is, at this point. It is not
> something that we can't change in the future once the code is in-tree.
With my 'upstream dev' hat on, I tend to be suspicious of this
line of argument, because in a lot of cases what tends to happen
is that the code for some new target or device goes in-tree, and
then the people who worked on submitting it disappear, or never
actually do get round to refactoring[*]. You get more leeway for
making this argument the longer you've been around and participating
in QEMU development, because then you have a track record of
following up on things.
[*] in fact we're currently discussing deleting support for
a couple of target architectures that were basically "once the
code went into mainline nothing further was ever done to it except
global-refactorings and other tree wide maintenance by other
QEMU developers".
thanks
-- PMM
Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission, Igor Mammedov, 2018/02/27
Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission, Michael Clark, 2018/02/27