MicroPython Forum (Archive)

One other thing that would be nice (directly related to embeddability) is to provide a "Micro Python amalgamation" ala sqlite. This is simply a concatenation of all uPy source files into one file (in the right order), plus a single header (and perhaps a single config file). This gives lowest barrier to entry using uPy, as users can very easily download and compile a single .C file, and it would provide them with a complete Python system.

Yes, I thought about amalgamation some time ago too. I would then be satisfied by just ability to create one file which would #include *.c, but that's not possible without guarded includes. So, doing them first step makes sense. Then, just producing a static lib makes sense. Self-contained amalgamation would be the last step.

Damien wrote:Okay, let's add loadable C modules as a 5th item.

There is actually already something we can use for this: the native emitter has a function table (see nativeglue.c) to "link" native code into the rest of the system.

Do you mean that as an example of approach, or to actually reuse emitter dispatch table as loadable module API? If you meant approach, that's what I meant either. The table should also contain API version number (and for a long time we'd need to check for "not equal", not "at least"), and good point that in uPy case, it'll need to contain a lot of data pointers in addition to functions. Then there would be defines like:
so a module can be both builtin and loadable.

I can point to https://github.com/pfalcon/squirrel-mod ... /binmodule as a complete example.

pfalcon wrote: Do you mean that as an example of approach, or to actually reuse emitter dispatch table as loadable module API?

I meant to actually reuse the native glue table, to save on code bytes. Of course we would need to add stuff (like you say the version number), but the majority of the calls already exist in this table, so why not use it?

I can point to https://github.com/pfalcon/squirrel-mod ... /binmodule as a complete example.

Yes, something like that, but in static/const table form.

Damien wrote:Okay, let's add loadable C modules as a 5th item.

For me they would idealy be: 1) portable/system independent; 2) completely static and not require any linking.

I'm not sure how to interpret the second point, especially the 'not require any linking' part, care to explain that some more?
Module source is built into a static library, then linked into the main uPy executable, some entry is added to a global dict with modules so they can be discovered?

No, "linking" happens at runtime using vtable, as described above.

stijn wrote:I'm not sure how to interpret the second point, especially the 'not require any linking' part, care to explain that some more?

By "no linking" I mean that I don't want to have to modify in any way the loaded C code. For efficiency and simplicity, but mainly so that such modules can be written to flash once, and then don't need any modification, and so can execute directly from flash (saving RAM). This way you could have a few 100k of C modules and not use any RAM.

An example of how it would work, consider the C function that add's 1 to its argument: This would compile to pseudo-assembler: The above assembler is position independent and requires no dynamic linking.

Yes I understand the part about using the function table - what I'm not grasping is how you load the code into the process?
Say there's a sourcefile containing the 'add_one' function which has to go in a module 'mymodule'. How do you go from that to
For unix dynamic libraries for example that is rather simple (which is probably why I don't see the other ways): add a function like init_mymodule which calls mp_obj_new_module and populates the returned modules' global dict with an entry for the add_one function. Build all that into a shared lib. When uPy sees 'import mymodule' it loads the lib, calls the init_mymodule function and that's it.
That can be altered to make use of mp_func_table_t in a way that makes no linking required (I think): either pass a pointer to init_mymodule and store it globally in the module and make all functions like add_one access the global, or add a new function type like mp_obj_fun_module_t which always gets the mp_func_table_t pointer as first argument.
But that is for a platform with unportable functions for loading executable code into a process - how do you do that without it?

Verifiable environment.

I think Micropython does have a great future as a minimalistic "operatingsystemless device" for
absolut secure devices.

(think about it as a signing or encrypting device, or digital key, or Bitcoin storage)

To be a secure device, the vectors of attac in a device should be minimal.

Micropython having no OS has very few attac vectors.

Microython is small enough to be codereviewed by one person. Linux 20 million lines of code can never
be code reviewed.

But developers must be able to receive the trust of the code reviewers of micropyhon. And they can if the whole system is
digitaly signed and versionverified.

The signing could be communicated by the board over LED to a mobile phone camera (sw could be compromised), or an oscilloscope,
or a simple film camera and read out and veryfied by a human.

So I think, making micropython image on the board verifiable would be a great feature.

just my 0.02 c

Not sure if I'm buying that: if you give me a board, and I can verify with a scope that it's ok, that doesn't tell me anything at all about the security of the code running it? For all I know you modified the source and made it do all kinds of evil, but just made sure the digital signing is still intact? The only way to trust it would be if I acquired, verified and built the source myself and uploaded it to the board. Just as everyone does now.