Qemu integration of the test suite #569
Conversation
|
There are a few issues that I wanted to discuss... Firstly, it currently fails on a number of tests due to modules missing in this port. Secondly, the output is perry messy and the only way to silence it would be by providing a dummy If you wanna try it out just |
|
What's this? Can commit message be made to provide more info than just a title line?
That's not going to get you very far, as #209 is pending anyway, and doing it instead what would make sense. And well, where're requirements for such kind of tesing? As you see yourself, it never will be able to handle imports, etc. Why instead not implement normal "frozen modules" support? |
|
Yeah, testing is nice, but why exactly such way to package tests, why tinytest, etc.? All in all, any testing is better than no testing, and this definitely can go as is, but it feels like interim solution which needs to be refactored along the way, maybe largely. So, if it took you 10 minutes for you to put together, it's ok. But if you put some effort to do it exactly this way, would be nice to know why. |
|
@pfalcon yeah, right... 10 minutes! I had rebased a bunch of times and had various versions of the |
|
@pfalcon could you please provide a pointer to how I'd implement frozen modules in uPy? |
|
@errordeveloper , well so there's no frozen modules support in uPy currently, though it was discussed. So it's basicly some trivial memory filesystem, plugged directly into import implementation. It should be really trivial to implement for "module" support, and my hunch is that it would be pretty similar with what you have in this patch. Supporting "packages" would be a little less trivial, but should be doable still. You can look at CPython's docs: https://docs.python.org/3.4/c-api/import.html#c._frozen Again, it's my IMHO that it's close to what you already did and doing it "frozen modules" way would be more general and useful (but probably would require few more issues to resolve on the way). You can disagree with this ;-). |
Looks good from side.
Thanks, much more clear now. Hope @dpgeorge will review it soon. |
|
Re: printf: well, usecase for its redirection is at least clear now, but I dodn't have specific suggestions. I'd just wait till #209 (but that's more or less big refactor). |
|
@pfalcon re: frozen modules; I see, actually I had a brief thought that what I did could be using a tar format, which is sort of like a filesystem... But if it's a whole chunk of modules we are thinking of, sure that needs to be pre-compiled to bytecode, otherwise it will occupy to much flash... Should we open an issue to discuss this? |
|
I see you found #222. But those are pretty orthogonal things - it's just when persistent bytecode will be supported, frozen modules will be able to contain not just source code, but bytecodes too. |
|
@pfalcon, I'm not sure if we are still on track. So you thought that I could try implementing this as frozen modules instead, which is clearly a lot more work then might be needed for what I wanted... And actually the test suite is currently not organised as modules, those scripts are all just standalone programs. In terms of what I wanted was to provide a base port for Qemu, so one can prototype various things with it. Let's say you want to write a driver for a sensor that you don't have and to make sure that it's well behaved you actually wrote a qemu device plugin (QDev) that models it. I think this is pretty valid, I might want to work on that actually and it'd be quite fun to use uPy instead of just doing the whole thing in C and it would be simple project to learn some Qemu internals and good for people to have as an example, as I haven't seen many QDev examples out there when I last checked. I didn't just sign up for this, not sure if I'll find the time, but just trying to give more indication why this port is a great playgound for some. I think we should state in the readme that this port is for:
|
|
Personally, I'm happy just debugging and testing right on the pyboard. The tests in tests/ can all be run directly on pyboard by But, I can see how qemu would be useful for difficult bugs, and profiling. I won't have the resources to maintain qemu, so hopefully I can leave it up to you and/or others. |
|
@errordeveloper : as I mentioned above, it's just IMHO that frozen modules go along the lines of what you're doing, for this patch I'm +1 to merge it as is. |
|
Ok, I personally think that it's very cool and potentially useful to have emulation support. Well, I remember old good times when I hacked on ability to write QEMU plugins (to implement devices, etc.) in Python. Wish I had time for that now, but it's fully worth to support such efforts IMHO. So, I assume @dpgeorge doesn't have better suggestions for support tools/libs locations, let me merge this then. |
|
Merged, while capturing pullreq description within commit message for further reference. @errordeveloper , please submit further patches if/when they will be ready, including port README updates you mentioned. Thanks! |
|
@errordeveloper If I understand your comment above properly and if you want to attempt an initial QEMU device for simulation - you might want to consider anything in this library: I mention this one because someone might well want to prototype talking to one of these devices before they have a physical device in hand to connect. |
|
@errordeveloper : Ping about discussed port README changes and integration of this testsuite into Travis CI (it doesn't run so far, right)? |
|
As of README, I started writing it actually, will try to finish today. With Travis, my dilemma is whether to implement a few relatively big On 20 May 2014 14:44, Paul Sokolovsky notifications@github.com wrote:
|
Thanks!
I guess just lead what this patch started to the logical end, i.e. make those tests which are possible to run with tinytest approach to actually run in Travis - is good enough. I guess it's fair to expect that during summer time, there will be slower pace of development, so would be nice to just make what's already done useful - otherwise there're already questions like in #619 (comment) Thanks! |
This is primarily intended to provide testing of Thumb-specific code within Travis CI as well as if anyone else want to run it locally. As discussed in #515, the idea of Qemu port had been mostly to build upon for testing purposes. This is currently agains an emulated Cortex-M3 core, however in the near future it can extended to support M0, M0+ as well M4 (work in progress exists in sushihangover/qemu).
It's probably true that most of the code base can be covered running uPy natively on a POSIX system, however we do have the tiny bit of assembly code. There may exist bugs related to endianness and type aliases, let alone potential standard library or compiler bugs or even architecture-specific optimisations.
This could also incorporate lwIP (or other TCP/IP stack) integration as well as SDIO+FATFS drivers.
The solution to inline the test cases was chose due to simplicity. It could alternatively be implemented in a number of different way (see #515), but this looked the simplest.
Inclusion of tinytest was just to avoid writing boilerplate code for counting failed tests and other utility functions. Currently only a few functions are used, however this could be extended. Checking in the code instead of using submodule was a personal preference, but if people do want the pain of submodules, this can provided. This particular framework is also pretty good if one desires to run unit test on target. The approach with scripts being inlined is probably not quite suited for the size of memory an MCU has, but the tinytest itself should be good, if lower-level C code is to be unit tested.