überSpark: Add libc and libcrypto üobject runtime libraries

This task will add support for a minimal libc and libcrypto üobject runtime libraries.

Linked PRs:

Can I request that with this task, there is also a minimal addition to the docs describing uobjrtls (e.g., are these different from standard libraries)? Also describing how they are invoked/referenced (e.g., in manifest)?

Yup, will do…Stay tuned…:slight_smile:

@Cap,

A quick thought as I was fleshing out this task:

I am thinking of using a separate namespace for each uobjrtl (uobject runtime library):

uberspark/uobjrtl/crt --> C runtime
uberspark/uobjrtl/crypto -> crypto functions

And within each uobjrtl namespace, the functions would follow the following naming scheme:
uberspark_uobjrtl_<rtname>__<rtfname>.

For example, within uberspark/uobjrtl/crt the functions would be named:

uberspark_uobjrtl_crt__memcpy, 
uberspark_uobjrtl_crt__strcpy, 

etc.

So from within any üobject, if you would like to use crt memcpy you would write:

#include <uberspark/uobjrtl/crt/include/string.h>
...
uberspark_uobjrtl_crt__memcpy(...);
...

The rationale behind this is to give uberspark specific functions its own distinct namespace when used within a üobject. In future, the üobject can then use any existing legacy header and/or invoke legacy functions without any namespace conflict when we add support for legacy sentinels.

Let me know your thoughts. Thanks!

@amitvasudevan,

I think that this provides good clarity and easily identify the rtl being invoked.

Are the uobjrtls part of the uberspark framework, or are they specified within the existing COSS codebase (or a combination of both)? In essence, do I specify my codebase’s libraries to be uobjrtls or are these uberspark built-in libraries?

I think this will help alleviate the issue I was experiencing where the compiler was throwing an error due to functions being redefined.

Are the uobjrtls part of the uberspark framework, or are they specified within the existing COSS codebase (or a combination of both)? In essence, do I specify my codebase’s libraries to be uobjrtls or are these uberspark built-in libraries?

uobjrtl’s are solely for use by üobjects.

OK, so uobjrtls essentially become “built-ins” provided by uberspark for the uobject being created.

As a developer, I simply reference that I am using these in the uberspark.json manifest and use the appropriate #include <...> in my source files. Then these function calls are disambiguated from legacy function calls by their uberspark_uobjrtl_<rtname>__<rtfname>(...) (where legacy would simply be <rtfname>(...))

Yes. Correct! :smiley:

Have created a PR for testing purposes; linked to OP.

It should bring in appropriate crt and crypto uobject runtime library modules and build it during the uobj collection build process.

Please refer to the using uobject runtime libraries in the developers guide and the reference for documentation regarding the current uobject runtime library functions. There is also a section in the contributors guide on uobject runtime libraries that explains how to add new runtime libraries and/or change existing ones.

I can merge this PR once you confirm it works on the task below:

Thanks!

PR merged:

Closing task topic.