Return to IOStatsMemo CVS log

Up to [Apple Darwin 0.x] / driverkit / notes

Annotation of driverkit/notes/IOStatsMemo, revision 1.1

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.