ioctl

Abstract: Python is an interpreted, object-oriented language suitable for many purposes. It has a clear, intuitive syntax, powerful high-level data structures, and a flexible dynamic type system. Python can be used interactively, in stand-alone scripts, for large programs, or as an extension language for existing applications. The language runs on UNIX, Macintosh, and DOS machines. Source and documentation are available by anonymous ftp. Python is easily extensible through modules written in C or C++, and can also be embedded in applications as a library. Existing extensions provide access to most standard UNIX library functions and system calls (including processes management, socket and ioctl operations), as well as to large packages like X11/Motif. There are also a number of system-specif ic extensions, e.g. to interface to the Sun and SGI audio hardware. A large library of standard modules written in Python also exists. Compared to C, Python programs are much shorter, and consequently much faster to write. In comparison with Perl, Python code is easier to read, write and maintain. Relative to TCL, Python is better suited for larger or more complicated programs.

Abstract: March 1994 he success of the Unix operating system is partly attributable to the design of its input/output facility. The primary Unix I/O abstraction is a sequential byte stream provided by an interface of system calls: open, read, write, seek, close, and ioctl. The I/O facility is simple and versatile and can be uniformly applied to a variety of I/O services, including disk files, terminals, pipes, networking interfaces, and other low-level devices. ’ Nevertheless, application programs running under Unix typically do not use the Unix I/O system calls directly. Instead, they use higher level facilities implemented either by the programming language or its application-level libraries for example, the stdio library for C or the iostream library for C++. I/O facilities at the application level offer several advantages. The interfaces can be made to match the programming-language syntax and semantics, and they can provide functionality not available at the system level. They increase application portability because the I/O facility can be ported to run under other operating systems. Application-level I/O facilities can also significantly improve application performance, primarily by buffering the input and output to translate multiple fine-grained application-level I/O operations into individual coarser grained system-level operations. For example, if an application inputs one character at a time, each can be serviced from an application-level buffer without a system call; a system-level read must be issued only when the buffer is empty. The interface and implementation of most application-level I/O facilities have changed little since the late 197Os.* However, the computing substrate the computer architecture, hardware technology, and operating system has changed substantially in the past 10 to 20 years, and we contend that application performance can be significantly improved by adapting both the implementation and interfaces of application-level I/O facilities to this change. This article introduces an application-level I/O facility. the Allot Stream Facility, that addresses three primary goals. First, ASF addresses recent computing substrate changes to improve performance, allowing applications to benefit from specific features such as mapped files. Second, it is designed for parallel systems, maximizing concurrency and reporting errors properly. Finally, its modular and object-oriented structure allows it to support a variety of popular I/O interfaces (including stdio and C++ stream I/O) and to be tuned to system behavior, exploiting a system’s strengths while avoiding its weaknesses. On a number of standard Unix systems, I/O-intensive applications perform substantially better when linked to our facility in the best case, up to twice as good.

Abstract: Described herein are systems and methods for preventing a user mode USB driver from performing IOCTL operations other than read-safe IOCTLs on a USB device that has been claimed by a kernel mode driver or is in use by another user mode USB driver. In one method, it is determined whether a kernel mode USB driver will claim a device or whether the device will be available to be claimed by user mode USB drivers. In the event the device is claimed by a kernel mode USB driver, user mode USB drivers will be prevented from claiming the device. In the event the device is available for use by user mode USB drivers, but has been opened for write by one user mode USB driver, all other user mode USB drivers will be prevented from claiming the device. All IOCTL operations other than read-safe IOCTLs will be prevented from being performed by a user mode USB driver unless that USB driver has claimed the device.

Abstract: A system and method for implementing any one of multiple communication protocols with a single device driver. During initialization (e.g., after being attached to network interface device), a device driver receives a call (e.g., an ioctl) identifying a protocol to be implemented (e.g., PPP or SRP). The device driver configures device soft state structures for each network interface device with protocol-specific attributes (e.g., MTU size, references to protocol-specific packet handling functions). In response to an upper level protocol request (e.g., DL_INFO_REQ), the device driver dynamically assembles protocol-specific data to answer the request.