OrgZephyr/zephyr
OrgZephyr
/
zephyr
mirror of https://github.com/zephyrproject-rtos/zephyr.git
1
0
Fork 0
Code Issues Releases Wiki Activity
zephyr/drivers/entropy/entropy_handlers.c

20 lines
503 B
C
Raw Normal View History

drivers: Rename `random` to `entropy` This should clear up some of the confusion with random number generators and drivers that obtain entropy from the hardware. Also, many hardware number generators have limited bandwidth, so it's natural for their output to be only used for seeding a random number generator. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-10-14 07:30:55 +08:00
/*
* Copyright (c) 2017 Intel Corporation
*
* SPDX-License-Identifier: Apache-2.0
*/
cleanup: include/: move entropy.h to drivers/entropy.h move entropy.h to drivers/entropy.h and create a shim for backward-compatibility. No functional changes to the headers. A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES. Related to #16539 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-26 03:53:49 +08:00
#include <drivers/entropy.h>
drivers: Rename `random` to `entropy` This should clear up some of the confusion with random number generators and drivers that obtain entropy from the hardware. Also, many hardware number generators have limited bandwidth, so it's natural for their output to be only used for seeding a random number generator. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-10-14 07:30:55 +08:00
#include <syscall_handler.h>
kernel: Port remaining syscalls to new API These calls are not accessible in CI test, nor do they get built on common platforms (in at least one case I found a typo which proved the code was truly unused). These changes are blind, so live in a separate commit. But the nature of the port is mechanical, all other syscalls in the system work fine, and any errors should be easily corrected. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-08-14 02:34:34 +08:00
static inline int z_vrfy_entropy_get_entropy(struct device *dev,
zephyr: replace zephyr integer types with C99 types git grep -l 'u\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g" git grep -l 's\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g" Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-05-28 00:26:57 +08:00
uint8_t *buffer,
uint16_t len)
drivers: Rename `random` to `entropy` This should clear up some of the confusion with random number generators and drivers that obtain entropy from the hardware. Also, many hardware number generators have limited bandwidth, so it's natural for their output to be only used for seeding a random number generator. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-10-14 07:30:55 +08:00
{
syscalls: remove policy from handler checks The various macros to do checks in system call handlers all implictly would generate a kernel oops if a check failed. This is undesirable for a few reasons: * System call handlers that acquire resources in the handler have no good recourse for cleanup if a check fails. * In some cases we may want to propagate a return value back to the caller instead of just killing the calling thread, even though the base API doesn't do these checks. These macros now all return a value, if nonzero is returned the check failed. K_OOPS() now wraps these calls to generate a kernel oops. At the moment, the policy for all APIs has not changed. They still all oops upon a failed check/ The macros now use the Z_ notation for private APIs. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-05-05 06:57:57 +08:00
Z_OOPS(Z_SYSCALL_DRIVER_ENTROPY(dev, get_entropy));
Z_OOPS(Z_SYSCALL_MEMORY_WRITE(buffer, len));
zephyr: replace zephyr integer types with C99 types git grep -l 'u\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/u\(8\|16\|32\|64\)_t/uint\1_t/g" git grep -l 's\(8\|16\|32\|64\)_t' | \ xargs sed -i "s/s\(8\|16\|32\|64\)_t/int\1_t/g" Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2020-05-28 00:26:57 +08:00
return z_impl_entropy_get_entropy((struct device *)dev, (uint8_t *)buffer,
drivers: Rename `random` to `entropy` This should clear up some of the confusion with random number generators and drivers that obtain entropy from the hardware. Also, many hardware number generators have limited bandwidth, so it's natural for their output to be only used for seeding a random number generator. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2017-10-14 07:30:55 +08:00
len);
}
kernel: Port remaining syscalls to new API These calls are not accessible in CI test, nor do they get built on common platforms (in at least one case I found a typo which proved the code was truly unused). These changes are blind, so live in a separate commit. But the nature of the port is mechanical, all other syscalls in the system work fine, and any errors should be easily corrected. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-08-14 02:34:34 +08:00
#include <syscalls/entropy_get_entropy_mrsh.c>