One request of the FILES screen to the card's task, and the runner that answers it: a page of a pane, a folder entered or left, the facts of one entry for INFO, or a job run to its end. More...

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include "card_tree.h"
#include "fm_io.h"
#include "fm_ops.h"
#include "fm_rules.h"
#include "fm_tree.h"

Data Structures
struct	fm_info_t
	What INFO reads of one entry. More...
struct	fm_req_t
	One request. The screen fills the fields of its kind, the runner writes the answer into the same request. More...
struct	fm_runner_t
	What the card's task gives the runner: the card, the bench as it stands, CANCEL, the progress, the look at the slot, and the room of one chunk. More...

Enumerations
enum	fm_req_kind_t { FM_REQ_NONE = 0 , FM_REQ_PAGE , FM_REQ_ENTER , FM_REQ_UP , FM_REQ_INFO , FM_REQ_JOB }
	What a request asks for. More...

Functions
fm_err_t	fm_req_run (fm_req_t req, const fm_runner_t run)
	Answer `req:` every card call it needs, to its end.
void	fm_req_bench (const fm_req_t req, fm_bench_t live)
	The bench the rules read for `req:` `live`, the bench as it stands, with the log folders the request carries.

Detailed Description

One request of the FILES screen to the card's task, and the runner that answers it: a page of a pane, a folder entered or left, the facts of one entry for INFO, or a job run to its end.

The screen makes no card call. It fills an fm_req_t, hands it to the card's task and does not touch it again until the task says it is answered; then it reads the answer from the same request. One request is under way at a time. The card's task calls fm_req_run(), which makes every card call of the request through the runner's fm_io_t:

PAGE fm_tree_page() of the pane the request carries ENTER fm_tree_enter() of its row UP fm_tree_up() INFO the size and time of one entry (fm_io_t stat()); for a folder also its entries and their bytes, from one walk JOB fm_job_step() until the job is no longer FM_JOB_RUNNING

The bench the rules and the write gate read is asked of the runner before each step, so a job learns of an ARM, a log run opening or the IOmcu link going at its next chunk. CANCEL is asked the same way. The log folders in force come from the request: the screen copies them in when it fills it, since they change only on SETUP.

Pure C, no ESP-IDF (Espressif Internet-of-Things Development Framework).

SPDX-License-Identifier: MIT

Enumeration Type Documentation

◆ fm_req_kind_t

enum fm_req_kind_t

What a request asks for.

Enumerator
FM_REQ_NONE	nothing: answered FM_ERR_ARG
FM_REQ_PAGE	a page of the pane: fm_tree_page()
FM_REQ_ENTER	the folder on a row: fm_tree_enter()
FM_REQ_UP	the folder above: fm_tree_up()
FM_REQ_INFO	one entry's facts for INFO
FM_REQ_JOB	a job of fm_ops.h, run to its end

Function Documentation

◆ fm_req_bench()

void fm_req_bench	(	const fm_req_t *	req,
		fm_bench_t *	live )

The bench the rules read for req: live, the bench as it stands, with the log folders the request carries.

Parameters

req	the request
live	the bench now, filled by the runner's bench()

◆ fm_req_run()

fm_err_t fm_req_run	(	fm_req_t *	req,
		const fm_runner_t *	run )

Answer req: every card call it needs, to its end.

A JOB is stepped until it is no longer FM_JOB_RUNNING, with the bench and CANCEL asked before each step; its answer is FM_OK when it is FM_JOB_DONE and the job's err otherwise. A JOB that is not running when it arrives, a refusal of its start, keeps that answer.