zephyr/tests/drivers/disk/disk_access
Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.

The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.

NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
2022-09-05 16:31:47 +02:00
..
src includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 2022-09-05 16:31:47 +02:00
CMakeLists.txt
README.txt
prj.conf tests: drivers: move the disk access test to new ztest API 2022-08-27 16:18:34 -04:00
testcase.yaml

README.txt

Disk Access Test
##################

This test is intended to verify the functionality of disk devices in Zephyr.
It is designed to test the NXP USDHC disk driver, but can be used for other
disk devices as well. The test has the following phases:

* Setup test: Verifies that disk initialization works, as well as testing
  disk_access_ioctl by querying the disk for its sector size and sector count.
  Note that this test also verifies the memory buffers reserved for read/write
  tests are sufficiently large, and will fail if they are not (in which case
  the value of SECTOR_SIZE must be increased)

* Read test: Verifies that the driver can consistently read sectors. This test
  starts by reading sectors from a variety of start locations. Each location is
  read from several times, each time with a different number of desired sectors.
  The test deliberately will read sectors beyond the end of the disk, and if
  the driver does not reject this read request the tests will fail. Following
  these sector reads, the driver will read multiple times from the same memory
  location, to verify that the data being returned is the same.

* Write test: Verifies that the driver can consistently write sectors. This test
  follows the same flow as the read test, but at each step writes data to the
  disk and reads it back to verify correctness. The test first performs writes
  of various length to various sectors (once again, the driver must reject
  writes that would be outside the bounds of the disk), then performs multiple
  writes to the same location.