I embarked on a project to modernize hal_lib to use linux-style doubly
linked lists instead of the homebrew singly-linked lists. One problem
along the way is halrmt, which uses hal private structures.
This gives a nice simplification of most list traversing code, like
this example:
- next = hal_data->comp_list_ptr;
- while (next != 0) {
- comp = SHMPTR(next);
- if (comp->comp_id == id) {
- /* found a match */
- return comp;
- }
- /* didn't find it yet, look at next one */
- next = comp->next_ptr;
- }
+ hal_list_for_each(ptr, &hal_data->comp_list) {
+ comp = hal_list_entry(ptr, hal_comp_t, list);
+ if (comp->comp_id == comp_id) return comp;
+ }
and also allows easier insertion at list end, and removal of list items.
When halrmt was written, halcmd did not have a nice factored out
interface. Now it does.
If someone is interested in halrmt continuing to work, she should
refactor it to use the "portable" APIs of halcmd instead of the private
APIs.
Use halcmd_parse_cmd or halcmd_parse_line from halcmd.h, illustrated by
halsh.c. This is a "durable" API that we don't expect to break without
very good reason.
This also requires a group of output-handling functions to be
implemented: halcmd_info halcmd_output halcmd_warning halcmd_error
halcmd_echo, which are all printf-style functions which carry halcmd
messages of varying severities.
Have a look at src/hal/utils/halsh.c for how halcmd is wrapped for use
from Tcl.
If this work is not done, I'll ultimately end up disabling halrmt, or
some halrmt functionality, as I modernize the private hal structures.
Jeff
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
