[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Separate cmd, mi and actions in the app sources
From: |
Jose E. Marchesi |
Subject: |
Re: [RFC] Separate cmd, mi and actions in the app sources |
Date: |
Mon, 11 May 2020 10:48:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
pk-cmd-ios.c --+
|
+--> pk-ios.c
|
pk-mi-ios.c ----+
Where:
- pk-mi.c contains the code that dispatches IOS-related requests to the
"semantic" routines in pk-ios.c. For example, it would translate a
REQUEST_OPEN_IOS to the corresponding pk_ios_open implemented in
pk-ios.c
- pk-cmd-ios.c contains the cmd machinery for the IOS-related
dot-commands. Basically what pk-ios.c contains nowadays, minus the
"semantic" routines.
- pk-ios.c contains the "semantic" routines to manipulate IOS. These
services are used
An example:consider opening an IO space.
This can be commanded in two ways:
- The user writes a dot-command in the REPL:
(poke) .file foo
- A client sends a REQ_IOS_OPEN request message thru the
machine-interface.
The dot-command is handled by code in pk-cmd-ios.c:
int
pk_cmd_file (argc, argv, uflags)
{
...
if (!pk_open_ios (...))
pk_printf ("cannot open file ...");
...
}
The MI message is handled by code in pk-mi-ios.c:
int
pk_mi_ios_open (msg)
{
...
if (!pk_open_ios (...))
{
put_in_response_msg ("cannot open file ...");
}
...
send_response;
}
And what I called the "semantic" routine in last email, pk_open_ios
itself, is implemented in pk-ios.c:
int
pk_open_ios (...)
{
...
... pk_ios_search ...
...
}
That's the idea.