-
Notifications
You must be signed in to change notification settings - Fork 0
/
_TODO.txt
181 lines (124 loc) · 8.39 KB
/
_TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
-------------------------------------------------------------------------------
---------------------
HERCULES TODO IDEAS
---------------------
(in absolutely *NO* particular order)
NOTE: ideally a separate GitHub "Issue" should be created for each of these!
-------------------------------------------------------------------------------
Determine optimal run_cpu/run_sie loop value taking into consideration
typical/average real host milliseconds/microseconds to complete a real
dasd I/O and typical/average number of typical workload guest instructions
that can be executed within that amount of time. The idea here is to NOT
continue looping executing guest instructions if there's a guest interrupt
waiting to be taken. This ensures timely guest notification that their
I/O has completed instead of having them "wait" much longer for the I/O
interrupt to occur because we're busy burning CPU executing instructions
instead of taking/processing an interrupt. (I.e. we don't want to "delay"
notifying them of their pending interrupts any longer than necessary.
IDEALLY we should call INTERRUPT_PENDING() macro after every instruction
but that slows Hercules down to crawl, which is why we execute multiple
instructions in a loop in the first place before calling INTERRUPT_PENDING()
macro. We don't want to call INTERRUPT_PENDING() macro TOO often, but we
should MAYBE be callingit more frequently than we are. The trick is to
determine HOW often is should be called for best performance ON A GIVEN
HOST SYSTEM. It should be a dynamially calculated value that is calculated
during startup to prevent our current defined fixed value from unfairly
penalizing those users with slower/faster Hercules host systems.
-------------------------------------------------------------------------------
Examine all instances of "#if 0" and "if 1" and determine which should
stay and which should go. For those that should be kept, add comments
documenting the rationale for keeping it.
-------------------------------------------------------------------------------
*BUG*: FIX PORTABILITY ISSUES that have crept in over time.
Remove all "#if defined(__APPLE__) || defined(__FreeBSD__)" statements.
You should NOT test for specific platforms. Instead, create a configure.ac
test for specific functionality or for feature a specific that your code
requires, and then #define HAVE_FEATURE_ABCXYZ if a platform supports it.
Then simply use #if defined(HAVE_FEATURE_ABCXYZ) in your Hercules code.
That way if a given platform begins supporting a feature that it previously
did not support, YOU DON'T HAVE TO CHANGE ANY HERCULES CODE AT ALL. This is
called "Writing portable code".
ONLY if you cannot design a test for the needed FEATURE within configure.ac
may you then add a test for a given platform, and then ONLY in "hostopts.h".
Our "hostopts.h" header is the ONLY SOURCE MODULE where tests for specific
platforms should be done. Test for the platform and #define your FEATURE
accordingly. Elsewhere in Hercules you then test for that #define FEATURE.
Windows is the only allowed exception to the rule. You may test for _MSVC_
or _WIN32, etc, but for non-Windows platforms #define HAVE_FEATURE_ABCXYZ
and then test for that instead.
Refer to "hostopts.h" for an example of the technique I'm referring to.
-------------------------------------------------------------------------------
DUMP command (Windows only) to create on-demand mini-dump.
modify fthread to maintain the thread's name in its FTHREAD list of
threads and provide a function to return a copy of that information
(linked list of thread ids and thread names), and then modify the
minidump BuildUserStreams function in bootstrap.c to save that info
so we can know which threads are which when we analyze a crash dump.
Add thread naming support to *Nix: autoconf: check for availability
of pthread_setname_np and pthread_getname_np functions.
-------------------------------------------------------------------------------
Suspend/Resume:
Add filename option to suspend/Resume command.
Resume option to issue start command if resume is successful.
Suspend/Resume command needs prompts/error messages: Ask Y/N confirmation
during suspend if overwriting existing suspend file, error message when
resume command given and machine is not in the reset state.
Add missing Suspend/Resume support to tape devices.
Add missing Suspend/Resume support to CTC devices.
-------------------------------------------------------------------------------
Add 'const' to as many functions' arguments as possible.
-------------------------------------------------------------------------------
Per Mark Gaubatz, we need a new dasd util to fix CE/SA alt cyl issue
for existing dasds created using the old dasdinit.
-------------------------------------------------------------------------------
Card reader: @stack support, like Ivan's tape autoloader, to provide
ability to specify different options (ascii/ebcdic) for each i/p file.
Then you could stack a VM USERID card in ebcdic followed by a normal
ascii text file (which would be auto-translated to ebcdic of course),
or vice-versa: an ascii USERID card followed by ebcdic binary data.
Would make getting VMARC files into VM much easier without having to
mess with a ebcdic USERID card.
-------------------------------------------------------------------------------
Maxrates off: reset/disable automatic maxrates
-------------------------------------------------------------------------------
Design a more platform generic host cpu features runtime check that
checks for the availability of certain host processor features
and then point any needed function-pointers to the correct function.
That way we can exploit certain host processor features when they're
available. Going through a function pointer is inefficient of course
(depending on where the function is being used), but depending on
what the function provides, it may be more of a gain than a loss.
E.g. (WIN64):
init_hostinfo:
BOOL WINAPI IsProcessorFeaturePresent( PF_COMPARE_EXCHANGE128 );
_INTEGRAL_MAX_BITS (machdep.h ==> _InterlockedCompareExchange128 ==> cmpxchg16b)
-------------------------------------------------------------------------------
Design a way for users to define command synonyms. (dynmod?)
-------------------------------------------------------------------------------
Windows block device support (i.e. ability to define an entire drive
(Windows drive letter / partition) as a Hercules dasd)
-------------------------------------------------------------------------------
Full 2540 reader/punch support! mode=1 (normal), mode=2 (binary/"card image")
hopper selection, etc.
-------------------------------------------------------------------------------
Ability to specify highlighting for console messages via regex pattern.
-------------------------------------------------------------------------------
ISSUE: there's the possibility for "socketpair" function to connect to some
other socket other than the pair's listening socket due to some other socket
on the host already listening for connections on INADDR_LOOPBACK. Fix is to
change the "socketpair" function to use a starting port# and SO_REUSEADDR
in a 'setsockopt' call and detect (HSO_errno == HSO_EADDRINUSE) return code
in its 'bind' call and auto-retry again using next port# (in a loop). Refer
to the "console_connection_handler" function for reference.
-------------------------------------------------------------------------------
Device or facility per Gerhard Postpischil's 9/20/2007 suggestion
that allows one to generate random "problems" (i/o errors, machine
checks, etc) for better software error recovery testing.
-------------------------------------------------------------------------------
Add new "+rdbwd" 3590-device-only option to set flag in
TapeCommands3590 table to allow/accept Read Backward CCW.
(Requested by "herc_fun" = Charlie <os_390@hotmail.com>)
-------------------------------------------------------------------------------
Generic native host SCSI support (mostly for tape,
but having it opens other interesting possibilities)
-------------------------------------------------------------------------------