On 28 February 2018 at 00:09, Michael Clark <m...@sifive.com> 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