Repository navigation
Conversation
|
So you can build MicroPython as a Linux kernel module, then |
Basically, yep. You can also place hooks and everything. The |
|
Wow, very cool! And good work writing the extensive README. I'll have to review it in more detail, but I'm +1 upon first glance. |
|
According to the readme, the REPL is exposed via TCP on all interfaces? wouldn't it be more (if at all) secure to only expose it via a character device file with root access only (i.e. something like a The lazy loading of globals to access kernel symbols looks interesting, but might be a bit confusing (typos may become a kernel symbol by chance, shadowed symbols)? maybe putting that into a module would make that more explicit, e.g. |
Cool :D
Usually I run this on QEMU and connect to the python via a host-only
If security is an issue - this can be easily changed to bind on a specific interface and possibly include some
Originally I had the globals on a separate module, but I valued typing speed and readability most, at least on the REPL, so I created the globals trick. I don't recall having any issue with this. However, it's totally a matter of taste, and we can add a runtime option to switch between those 2 modes, something like |
|
With some changes in pyboard.py, I managed to run the tests: I guess some work has to be done... :) |
|
Thanks All of you.
…On Mon, Jan 6, 2020, 06:33 Yonatan Goldschmidt ***@***.***> wrote:
With some changes in pyboard.py, I managed to run the tests:
591 tests performed (15390 individual testcases)
408 tests passed
64 tests
I guess some work has to be done... :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5482?email_source=notifications&email_token=AEYAML3FI6ZUYHLZIDSFUNLQ4JU3LA5CNFSM4KB36G2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIECOCI#issuecomment-570959625>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEYAML6CSPAJK25JEMZ7V33Q4JU3LANCNFSM4KB36G2A>
.
|
Yes, let's work on that first. One of those PR's is now merged (EMACS REPL), and the other two are pending revision. Please try to split out all other core changes to separate PRs. Ideally this PR would add files only to the new |
I'll move everything that's logically okay to be separate. The remains are, currently:
|
|
Rebased on latest master. Latest changes include:
Takes about 8 minutes to run.
I've added 1 basic linux-kernel specific test, I've got ideas for a few more though. |
Allow ports to provide a lazy load function for undefined globals.
Use it to remain with the default MPZ_DIG_SIZE = 32 on 64-bit builds.
Still has a long way to go, but IMO this is already proved useful when you need to prototype APIs / monitor specific data.
Importing Python files from the filesystem works as expected.
Uses my "struct_layout" project, written for this purpose.
Defined in 'include/linux/compiler_attributes.h', and it messes up with MicroPython's MP_FALLTHROUGH.
Instead of reimplementing it here :p
…AGE_KERNEL_EXEC pages in new kernels.
|
I have rebased this branch on v1.16; the old commit (as of 7f2a088) is available at https://github.com/Jongy/micropython/tree/linux-kernel-v1.12. This is Additionally, I have added some commits from the past few months of my work on making this build on Aarch64. Builds and runs but I haven't tested it very thoroughly. |
…n-main Translations update from Weblate
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
|
This feels conceptually similar to the recent UEFI port (#19432) in that they both use MicroPython to give insight into systems that are usually ruthlessly arcane and opaque (at least to us mere mortals). With respect to both I do wonder what constitutes an upstream port of MicroPython and what should be a consumer of the "embed" port. It feels like this has died on the vine, where a separate project with enough noise around it and that just happened to embed MicroPython (like you might do with Lua, but without the headache-inducing syntax) could have thrived. |
Yes, I think probably the most sustainable way for MicroPython as a project to support these kind of very cool efforts is to make it easy as possible to maintain an out-of-tree port. Otherwise, merging a new port like this either requires a long-term commitment from the author to maintain it (in which case, it could as easily be out-of-tree) or a commitment from the MicroPython maintainers to adopt it (which is particularly tricky in cases like this where we're integrating into a third party complex system on its own.) "Free as in puppy" springs to mind. 😁 So, in that spirit, I am keen to hear about any MicroPython changes that would make it easier to maintain out-of-tree port (for example, so MicroPython could be a submodule in the port rather than requiring the port to live inside a full fork of MicroPython.) I am going to close this PR though, as it seems like it's no longer being actively worked on. |
@Gadgetoid I think that the UEFI port and this are more different than they are similar. In my mind the distinction lies in the preposition: this is an embedded port designed to sit in the kernel while the UEFI port sits on a minimal, low level set of hardware abstractions. Embedding MicroPython inside some rich, complex other system is useful for many things, but it is a long way from MicroPython's origin of providing a clean way to directly bang on IO using a high level language from a REPL. The UEFI port on the other hand isn't quite a bare metal port, but it is all about direct access to the hardware without any OS to help. In fact in many ways UEFI gives the developer less abstraction and fewer services than Zephyr. Yes, a normal PC these days has a great deal more RAM and a much faster CPU than the original PyBoard, but there are PCs in the field running UEFI that have less CPU power and RAM than some Espressif ESP32-S31 boards, and nobody seems to be concerned with MicroPython being there. My personal feeling is that size here shouldn't matter. What should matter is if this is running on some system without memory protection, process separation or much of any runtime. By that count on UEFI aligns with the ethos much better than in anything. I freely admit that this is just my personal opinion, and others are welcome to disagree, but I wanted to add my tuppence worth. |
9 participants
I've been working on this port in the past month. It started as a fun PoC but I realized its usefulness for kernel research & debugging so I kept expanding it. It shows how powerful MicroPython is, due to the relative ease of porting it.
I'd happily continue maintaining it in a fork, but I prefer mainlining if possible. I think it'll be more accessible for others to contribute. @dpgeorge it's up to you.
TODOs list before merge, as I see it:
complete previous PRs required for this, and perhaps split out more unrelated commits into separate PRs.
create a convenient way to run MicroPython's tests on this port
actually run the whole test suite using the above method