mirror of
				https://source.denx.de/u-boot/u-boot.git
				synced 2025-10-31 16:31:25 +01:00 
			
		
		
		
	We are now using an env_ prefix for environment functions. Rename these two functions for consistency. Also add function comments in common.h. Quite a few places use getenv() in a condition context, provoking a warning from checkpatch. These are fixed up in this patch also. Suggested-by: Wolfgang Denk <wd@denx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot machine/arch independent API for external apps
=====================================================
1.  Main assumptions
  - there is a single entry point (syscall) to the API
  - per current design the syscall is a C-callable function in the U-Boot
    text, which might evolve into a real syscall using machine exception trap
    once this initial version proves functional
  - the consumer app is responsible for producing appropriate context (call
    number and arguments)
  - upon entry, the syscall dispatches the call to other (existing) U-Boot
    functional areas like networking or storage operations
  - consumer application will recognize the API is available by searching
    a specified (assumed by convention) range of address space for the
    signature
  - the U-Boot integral part of the API is meant to be thin and non-intrusive,
    leaving as much processing as possible on the consumer application side,
    for example it doesn't keep states, but relies on hints from the app and
    so on
  - optional (CONFIG_API)
2. Calls
  - console related (getc, putc, tstc etc.)
  - system (reset, platform info)
  - time (delay, current)
  - env vars (enumerate all, get, set)
  - devices (enumerate all, open, close, read, write); currently two classes
    of devices are recognized and supported: network and storage (ide, scsi,
    usb etc.)
3. Structure overview
  - core API, integral part of U-Boot, mandatory
    - implements the single entry point (mimics UNIX syscall)
  - glue
    - entry point at the consumer side, allows to make syscall, mandatory
      part
    - helper conveniency wrappers so that consumer app does not have to use
      the syscall directly, but in a more friendly manner (a la libc calls),
      optional part
  - consumer application
    - calls directly, or leverages the provided glue mid-layer