qemu-i386 port

Hi, we now have the third person wondering about the qemu-i386 port. Fact is, it doesn't work (we do not even have the unittests activated anymore). Is there a reason why we did not drop it yet (except making all the good work by René void)? Or are we planning to provide better support for it in the future?

Cheers, Martine

Hi Martine,

Git does not forget, so even if the "board" is rm -rf'd for now nothing is lost. The current state is probably worse then not having the board at all. Shall I open a PR to pull the port, so it is obvious that the author is OK with the decision?

Best, René

Hi!

We should drop a hint somewhere that these boards did exist once

so that interested people can pick up the work from git’s history.

I agree with dropping qemu-i386

On the same subject, would it make sense to clean up some other boards with less than ideal support? chronos is one board which I frequently run into trouble with because it is never up to date with the other platform implementations, especially the stdio is very hacky on that board.

/Joakim

Hi,

I'm all for cleaning up stale boards, especially I'd they are as hard to obtain as for example the FU boards. If I'm not mistaken this would also enable the removal of at least one legacy driver interface (I have some GPIO API in mind).

Cheers, Ludwig

Hi Ludwig, well at least the FU boards are now "obtainable" through the IoT-Lab testbed. :wink:

Cheers, Martine

All of them?

Hey!

Hey,

This discussion is also related to https://github.com/RIOT-OS/RIOT/pull/5412#issuecomment-237688208 I'm trying to enhance support for ek-lm4fxl-120 board, which is not as popular as stm boards... It's a bit complicated to find reviewers with some extra time for reviewing, and even more for hardware testing...

Would it be possible to have an in-between set of boards (between "well supported/tested" and "in the trash") ? Where reviewers could omit the hardware tests for example and rely on the "community" to do such tests ?

I must admit that having to spend several weeks for each small PR is a bit frustrating, but I fully understand that nobody really cares about this board. If this is not possible, then maybe you're right and boards that can't be maintained should be ditched. People can still maintain their own fork (what I'll probably do for TivaC board).

Marc

Hi,

Without any further insights I would say your case is different because the board is actively maintained, used, and can be bought. In the case of the FU boards I had in mind (msb430*) none of these points is true.

Cheers, Ludwig

[ek-lm4f120-xl board can't be bought anymore, only its replacement TivaC can (and it is not supported by RIOT, at least at the moment)]

It is actively maintained... sort of. I have the feeling that no RIOT developer has time for it. It is not listed on the RIOT wiki and it is hard to find someone with time and hw. If that's considered normal, then so be it and I'll happily continue to ping my PRs from time to time. I may even contribute a wiki page for it :slight_smile:

Sorry if this subject is considered OT, Cheers,

Marc

Hi Ludwig!

Without any further insights I would say your case is different because the board is actively maintained, used, and can be bought. In the case of the FU boards I had in mind (msb430*) none of these points is true.

While I agree with your assessment, I don't think we should drop support for MSB430 platforms. First, we have plenty of them in Berlin and Hamburg and I will happily lend them to anyone asking for it. Second, they are (or at least were) used in other academic institutes in WSN area. Finally, they are very similar to widely used platforms such as TelosB or WSN430 and the additional maintenance effort is really small. However, we definitely should try harder to get a better support for MSP430 platforms in general.

Cheers, Oleg