![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to IOStatsMemo CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple Darwin 0.x] / driverkit / notes|
Return to IOStatsMemo CVS log | Up to [Apple Darwin 0.x] / driverkit / notes |
1.1 root 1: {\rtf0\ansi{\fonttbl\f0\fmodern Ohlfs;\f1\fmodern Courier;}
2: \paperw13040
3: \paperh10200
4: \margl120
5: \margr120
6: {\colortbl\red0\green0\blue0;}
7: \pard\tx1152\tx2304\tx3456\tx4608\tx5760\tx6912\tx8064\tx9216\tx10368\tx11520\f0\b0\i0\ul0\fs24 At a meeting last Friday on the general subject of the NRW Token Ring driver, a subject came up which potentially applies to all NRW and IODevice-based drivers. This is the issue of a general "get and set parameters" mechanism which can be used on all drivers - in the Kernel and in user space - from User level Apps and utilities like iostat, netstat, and device-speciifc configuration utilities. iostat needs to get disk tty statistics; network interfaces need to be configured for transfer rate or "which wire" (TPE or thin wire), etc. \
8: \
9:
10: \f1\b\fs28 The problems:
11: \f0\b0\fs24 \
12: \
13: * There is no unified name space for device drivers in the Kernel. There is\
14: nmserver for drivers in User space, but that's not really useful for looking\
15: up devices you don't know anything about, and Kernel drivers can't advertise\
16: in the nmserver. The name space issue is a hot button for 4.0.\
17: \
18: * There will be no Remote Object functionality in the 3.0 or 3.1 Kernel.\
19: \
20:
21: \f1\b\fs28 The goals:
22: \f0\b0\fs24 \
23: \
24: * We want a simple, extensible mechanism by which an App or utility can \
25: contact any driver and get or set any integer paramater specific to \
26: that driver. \
27: \
28: * We want a mechanism which will work the same - from an App's point of \
29: view - for Kernel drivers and User drivers.\
30: \
31:
32: \f1\b\fs28 The Proposal:
33: \f0\b0\fs24 \
34: \
35: * The App/utility API for the proposed mechanism involves three new RPCs. \
36: These can be executed by any task with root privileges.\
37: \
38:
39: \fc0 to find out what's there:\
40: \
41:
42: \f1 dev_return_t
43: \b dev_inquire
44: \b0 (\
45: port_t
46: \i device_master
47: \i0 , \
48: int
49: \i devUnit
50: \i0 , // global device "unit num space"\
51: devtype_t *
52: \i devType
53: \i0 , // e.g., "SCSIDisk", "Ethernet", etc.)\
54: devname_t *
55: \i devName
56: \i0 // e.g., "BlockSCSIDisk0a"\
57: );\
58:
59: \f0 \
60: to get general parameter for devUnit n:\
61: \
62:
63: \f1 dev_return_t
64: \b dev_param
65: \b0 (\
66: port_t
67: \i device_master
68: \i0 ,\
69: int
70: \i devUnit
71: \i0 ,\
72: char
73: \i paramName
74: \i0 [PARAM_NAME_SIZE],\
75: int *
76: \i parameter
77: \i0 , // returned\
78: );\
79:
80: \f0 \
81: to set general parameter in devUnit n:\
82: \
83:
84: \f1 dev_return_t
85: \b dev_set_param
86: \b0 (\
87: port_t
88: \i device_master
89: \i0 ,\
90: int
91: \i devUnit
92: \i0 ,\
93: char
94: \i paramName
95: \i0 [PARAM_NAME_SIZE],\
96: int
97: \i parameter
98: \i0 // returned\
99: );\
100:
101: \f0 \
102: The dev_inquire() call is used to find out what devices are "out there". Once an App finds a devUnit corresponding to a device its interested in dealing with, it uses that devUnit for further operations. \
103: \
104: dev_param() and dev_set_param() are used to get and set any arbitrary parameter for a specified devUnit; the parameter is addressed by string paramName.\
105: \
106: * For IODevice-based drivers, there are two new instance varibales and \
107: two new methods:\
108: \
109: New IODevice instance variables:\
110: \
111:
112: \f1 typedef char devType_t[DEV_TYPE_SIZE];\
113: typedef char devName_t[DEV_NAME_SIZE];\
114: \
115: devType_t devType;\
116: devName_t devName;\
117:
118: \f0 \
119: A driver must initialize these instance variables prior to calling the \
120: existing registerDevice: method.\
121: \
122: New IODevice methods:\
123: \
124:
125: \f1 - (dev_return_t)getParam:(const char *)paramName param:(int *)parameter;\
126: - (dev_return_t)setParam:(const char *)paramName param:(int)parameter;\
127:
128: \f0 \
129: Any subclass can override these to handle new parameters; any not known \
130: are passed up to [super getParam:]. Thus, standard NetDriver parameters\
131: like "inPackets" can be handled by the NetDriver superclass, which \
132: subclasses can implement their own device-specific parameters, leaving \
133: the standard ones to NetDriver.\
134: \
135: e.g. in NetDriver:\
136: \
137:
138: \f1 - (int)getParam:(const char *)paramName\
139: \{\
140: if(strcmp(paramName, "inPackets"))\
141: return (if_ipackets([self getNetif]);\
142: else if (...)\
143: return whatever;\
144: else\
145: return [super getParam:paramName];\
146: \}\
147:
148: \f0 \
149: * It's a trivial matter to map devUnit numbers to id's of IODevice instances\
150: which register themselves via registerDevice:. \
151: \
152: Note that there will be a separate "devUnit" space for Kernel and User. The Three new RPCs defined above will work the same for both. \
153: \
154: That's my proposal. Some questions:\
155: \
156: * How do people feel about addressing parameters by string rather than by \
157: #defined or enumerated ints?\
158: \
159: * Will this "one integer parameter at a time" mechanism be sufficient?\
160: \
161: Comments?\
162: \
163: --dpm
164: }
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.