Special fields can be used to pass extra parameters to a device, and DeviceFS can sort them into a more useful format using a validation string. If a device does not want to use the DeviceFS mechanism it should pass 0 as the validation string pointer and be prepared to ignore unknown parameters in the special field.
Validation strings consist of keywords and escapes of the form
{keyword[,keyword]/escape[/escape]}*
escape is permitted two values:
/N number
/S switch
The special field is concatenated with the system variable DeviceFS$device$Options, then parsed according to the validation string and the results placed into a buffer. The buffer has one word per escape, which is set to &DEADDEAD if the keyword is absent from the special field. "Parameters" are terminated by a comma, or an out of place character (e.g. letter in a numeric field), and keywords are separated with a semicolon.
Numbers are read with OS_ReadUnsigned and stored in the word, switches store the number of the parameter in the switch's validation string.
See an example.
The special field control block of the Initialise entry point is a pointer to this block. It is not possible to read the original string.
DeviceFS special field example
Given a device called Serial and a validation string of
baud,rate/Nnohandshake,xon,rts,dtr/Snoparity,even,odd/Sdata/N
the file name serial#baud19200;noparity: would yield
0 19200 number
4 &DEADDEAD handshake keyword not supplied
8 0 noparity is first entry in switch
12 &DEADDEAD data keyword not supplied
and serial#rate28800;dtr;even;data7: would yield
0 28800 rate is an alias for baud
4 3 dtr is fourth entry in switch
8 1 even is second entry in switch
12 7 number
"Parameters"
"Parameters are separated by commas", "keywords separated by semicolons" gives the impression that the system was intended to support string parameters in addition. Block devices are in the API, yet are unimplemented - was DeviceFS only partially implemented?
[sh-index] Back to list of manuals
|
| |
