US5815707A
Expired / Lapsed
US
⏱️ 0.0 years remaining
Dynamic function replacement for streams framework
Assignee: Hewlett Packard Enterprise Development LP
•
Filing: 1995-10-19
•
Granted: 1998-09-29
•
Expires: 2015-10-19
Abstract
Abstract An extension to the STREAMS framework, referred to as dynamic function replacement, uses data structures that contain function pointers which allow STREAMS to execute various module or driver functions without requiring framework modification, or understanding what these functions actually do beyond their rudimentary classifications. This provides a simple, yet elegant, mechanism for replacing these function definitions and, hence, changing the execution behavior of STREAMS modules and drivers without requiring the modules or drivers to be rewritten or modified.
Inventors
- 👤 Michael R. Krause
- 👤 Yoshihiro Ishijima
Bibliographic Details
Application Number
—
Jurisdiction
US
Data Source
google_patents
Last Synchronized
2026-11-09 03:08
CPC Classifications
G; G06; G06F; G06F9/00; G06F9/06; G06F9/46; G06F9/54; G06F9/44; G06F9/448; G06F9/4482; G06F9/4484; G06F9/4486; H; H04; H04L; H04L67/00; H04L67/01; H04L67/10; H04L69/00; H04L69/30; H04L69/32; H04L69/322; H04L69/329
Claims Analysis
Total Claims: 32
Claim 1
Independent Claim
207 words
A data structure implemented in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, the data structure comprising: a normal function that implements a specific module or driver instance; at least one alternative function that implements an optional module or driver instance; and a controller for generating a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 2
Dependent Claim
207 words
A data structure implemented in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, the data structure comprising: a normal function that implements a specific module or driver instance; at least one alternative function that implements an optional module or driver instance; and a controller for generating a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 3
Dependent Claim
25 words
The data structure of claim 1, further comprising: an alternative function that customizes system tracing facilities to trace only specific events or under specific conditions.
Claim 4
Dependent Claim
25 words
The data structure of claim 1, further comprising: an alternative function that provides support facilities for applying custom failure catchers to target specified system problems.
Claim 5
Dependent Claim
20 words
The data structure of claim 1, further comprising: an alternative function that applies a patch on a per instance basis.
Claim 6
Dependent Claim
30 words
The data structure of claim 1, further comprising: an alternative function that allows testing to a single data path and that allows increased flexibility and control of data path execution.
Claim 7
Dependent Claim
28 words
The data structure of claim 1, further comprising: an alternative function that allows replacement of either all module or driver instances or replacement on a per instance basis.
Claim 8
Dependent Claim
15 words
The data structure of claim 1, wherein said system is implemented in a STREAMS framework.
Claim 9
Dependent Claim
21 words
The data structure of claim 7, wherein each module or driver defines a streamtab structure that contains pointers to qinit structures.
Claim 10
Dependent Claim
27 words
The data structure of claim 8, wherein said qinit structures are for read, write, read multiplexor, and write multiplexor queues which are created by said STREAMS framework.
Claim 11
Dependent Claim
35 words
The data structure of claim 8, wherein said qinit structures contain function addresses for open, close, put, service, and administrative functions which are invoked by said STREAMS framework on behalf of a module or driver.
Claim 12
Dependent Claim
51 words
The data structure of claim 8, wherein functions defined within said qinit structures are automatically executed by said STREAMS framework based on a current application execution path, and wherein said controller generates control commands that remap addresses of said structures to alternative streamtabs and qinit structures that define new function addresses.
Claim 13
Dependent Claim
30 words
The data structure of claim 11, wherein all contents of said qinit structures of an default alternative streamtab are identical to those of a normal streamtab except for put routines.
Claim 14
Dependent Claim
25 words
The data structure of claim 8, said controller further comprising: at least one STREAMS ioctl command that is used to alternate dynamically STREAMS module's/driver's streamtab's.
Claim 15
Dependent Claim
23 words
The data structure of claim 13, said controller further comprising: an ioctl command that is used to alter active instances of a module.
Claim 16
Dependent Claim
23 words
The data structure of claim 13, said controller further comprising: an ioctl command that is used to alter future instances of a module.
Claim 17
Dependent Claim
231 words
A data structure implemented in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, said system being implemented in a STREAMS framework in which each module or driver defines a streamtab structure that contains pointers to qinit structures, the data structure, comprising: a normal function that implements a specific module or driver instance; at least one alternative function that implements an optional module or driver instance; and a controller for generating a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 18
Dependent Claim
231 words
A data structure implemented in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, said system being implemented in a STREAMS framework in which each module or driver defines a streamtab structure that contains pointers to qinit structures, the data structure, comprising: a normal function that implements a specific module or driver instance; at least one alternative function that implements an optional module or driver instance; and a controller for generating a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 19
Dependent Claim
25 words
The data structure of claim 16, further comprising: an alternative function that customizes system tracing facilities to trace only specific events or under specific conditions.
Claim 20
Dependent Claim
25 words
The data structure of claim 16, further comprising: an alternative function that provides support facilities for applying custom failure catchers to target specified system problems.
Claim 21
Dependent Claim
20 words
The data structure of claim 16, further comprising: an alternative function that applies a patch on a per instance basis.
Claim 22
Dependent Claim
28 words
The data structure of claim 16, further comprising: an alternative function that allows testing to a single path and that allows increased flexibility and control of path execution.
Claim 23
Dependent Claim
28 words
The data structure of claim 16, further comprising: an alternative function that allows replacement of either all module or driver instances or replacement on a per instance basis.
Claim 24
Independent Claim
238 words
A method for implementing a data structure in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, said system being implemented in a STREAMS framework in which each module or driver defines a streamtab structure that contains pointers to qinit structures, the method comprising the steps of: providing a normal function that implements a specific module or driver instance; providing at least one alternative function that implements an optional module or driver instance; and generating, with a controller, a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 25
Independent Claim
238 words
A method for implementing a data structure in a computer system that provides a bidirectional data path between a user process, a module which is an intermediate processing element that can be dynamically added to, or removed from, said data path, and a device driver, said device driver being resident in a system kernel and controlling a peripheral device to transfer data between said kernel and said device, where data written by said user process travel downstream toward said driver, and where data received by said driver from said device travel upstream to be retrieved by a user, said system being implemented in a STREAMS framework in which each module or driver defines a streamtab structure that contains pointers to qinit structures, the method comprising the steps of: providing a normal function that implements a specific module or driver instance; providing at least one alternative function that implements an optional module or driver instance; and generating, with a controller, a control command that remaps addresses of said normal function and said at least one alternative function to define new function addresses that dynamically replace said normal function with said at least one alternative function, thereby implementing said optional module or driver or instance to dynamically change the execution behavior of said data structure, while either still executing an original execution path or executing a new execution path, and without requiring any modification to said module and said driver.
Claim 26
Dependent Claim
26 words
The method of claim 22, wherein said qinit structures are for read, write, read multiplexor, and write multiplexor queues which are created by said STREAMS framework.
Claim 27
Dependent Claim
34 words
The method of claim 22, wherein said qinit structures contain function addresses for open, close, put, service, and administrative functions which are invoked by said STREAMS framework on behalf of a module or driver.
Claim 28
Dependent Claim
51 words
The method of claim 22, further comprising the steps of: automatically executing functions defined within said qinit structures by said STREAMS framework based on a current application execution path; and generating a control command to remap addresses of said structures to alternative streamtabs and qinit structures that define new function addresses.
Claim 29
Dependent Claim
29 words
The method of claim 22, wherein all contents of said qinit structures of an default alternative streamtab are identical to those of a normal streamtab except for put routines.
Claim 30
Dependent Claim
23 words
The method of claim 22, further comprising the step of: using at least one STREAMS ioctl command to alternate dynamically STREAMS module's/driver's streamtab's.
Claim 31
Dependent Claim
21 words
The method of claim 27, further comprising the step of: using an ioctl command to alter active instances of a module.
Claim 32
Dependent Claim
21 words
The method of claim 27, further comprising the step of: using an ioctl command to alter future instances of a module.
References Cited (Backward Citations)
USPTO Annuity & Maintenance Windows
| Annuity Stage | Window Opens | Payment Deadline | Surcharge Period Until | Estimated Fee | Status |
|---|---|---|---|---|---|
| 3.5 Years (Year 4) | 2001-09-28 | 2002-03-30 | 2002-09-29 | $2000.00 | Window Closed / Lapsed |
| 7.5 Years (Year 8) | 2005-09-28 | 2006-03-30 | 2006-09-29 | $3760.00 | Window Closed / Lapsed |
| 11.5 Years (Year 12) | 2009-09-28 | 2010-03-30 | 2010-09-29 | $7700.00 | Window Closed / Lapsed |