[riot-notifications] [RIOT-OS/RIOT] wolfSSL pkg addition with examples (#7348)
notifications at github.com
Thu Sep 21 00:56:29 CEST 2017
As far as I can see, there is actually not much board specific configuration that isn't solved already:
> 2.1 Data Types
Setting the correct data type size for your platform is always important.
I'm sure this is configured for each supported board and can be found somewhere in `boards/` or `cpu/`
> 2.2 Endianness
Necessary if your platform is a big endian system.
Same as above
> 2.3 writev
Necessary if <sys/uio.h> is not available.
Should be available on every board via posix interface, I'm not sure if this is necessary
> 2.4 Input / Output
Necessary if a BSD-style socket API is not available, you are using a custom transport layer or TCP/IP stack, or only want to use static buffers.
This should be configured to use GNRC if possible
> 2.5 Filesystem
Necessary if file system is not available, standard file system functions are not available, or you have a custom file system.
> 2.6 Threading
Necessary if you want to use wolfSSL in a multithreaded environment, or want to just compile it in single threaded mode.
This could be left out and eventually ported later if necessary
> 2.7 Random Seed
Necessary if either /dev/random or /dev/urandom is not available or you want to integrate into a hardware RNG.
I would suggest using RIOT's random module, initialized with a hwrng if available
> 2.8 Memory
Necessary when you don’t have standard memory functions available or are interested in memory usage differences between optional math libraries.
This could be the biggest problem as free is currently not doing anything, also fastmath
> 2.9 Time
Necessary when standard time functions are not available, or you need to define a custom clock tick function.
Not sure if this is available or must be configured, but it should be uniform between all supported boards
> 2.10 C Standard Library
Necessary when a C standard library is not available, or using a custom one.
Should be working
> 2.11 Logging
Necessary when debug messages desired but stderr is unavailable.
Uniform between boards
> 2.12 Public Key Operations
Necessary if you want to use your own public key implementation.
We don't have one as far as I can see
> 2.13 Atomic Record Layer Processing
Necessary if you want to do your own processing of record layers, specifically MAC/encrypt and decrypt/verify operations.
Not sure if this is needed but it's not board specific
> 2.14 Features
Necessary when you want to disable features for example if memory constrained you could disable features to reduce footprint size.
This is mostly application specific
So summarizing the above: if we find out where to get each boards data type sizes and endianness, we should be able to solve most of the configuration for all supported boards in a generic way.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications