Abstract: A computing device includes a storage device having a file and a file system for storing and retrieving the file on the storage device. The file includes a plurality of segments, where each of at least some of the segments is null data and each of at least some of the segments is substantive data. The file has space allocated therein for each null data segment but such allocated space is not actually filled with information, and the file has space allocated therein for each substantive data segment and such allocated space is actually filled with information. Each null data segment is not actually physically stored on the storage device and each substantive data segment is actually stored on the storage device.

Abstract: An application issues an application command to a file system of the computing device, where the application command includes a location of data at a source. The file system allocates space on a medium for the data and compiles a list including an identification of each portion of the medium that is to be used to store the data. The file system then issues a file system command to a block driver of the medium, where the file system command includes the location of the data at the source and the compiled list. The block driver contacts the source, requests the data at the location thereof, and writes the data to the portions of the medium included in the compiled list.

Abstract: An application issues an application command to a file system of the computing device, where the application command includes a location of data at a source. The file system allocates space on a medium for the data and compiles a list including an identification of each portion of the medium that is to be used to store the data. The file system then issues a file system command to a block driver of the medium, where the file system command includes the location of the data at the source and the compiled list. The block driver contacts the source, requests the data at the location thereof, and writes the data to the portions of the medium included in the compiled list.

Abstract: Concepts for enhancing operation of transaction-safe file allocation table systems are described. The concepts include writing a file to non-volatile memory media and rendering an update of file size to the TFAT storage medium; and receiving a request to locate data in a non-volatile memory having a TFAT file management system, selecting a sector of the memory to parse to locate the data, determining when the selected sector is a first sector of a directory or subdirectory of the memory and when determining reveals that the selected sector is a first sector, skipping reading data from the selected sector. The concepts also include flushing a cache and synchronizing FATs.

Abstract: Concepts for enhancing operation of transaction-safe file allocation table systems are described. The concepts include writing a file to non-volatile memory media and rendering an update of file size to the TFAT storage medium; and receiving a request to locate data in a non-volatile memory having a TFAT file management system, selecting a sector of the memory to parse to locate the data, determining when the selected sector is a first sector of a directory or subdirectory of the memory and when determining reveals that the selected sector is a first sector, skipping reading data from the selected sector. The concepts also include flushing a cache and synchronizing FATs.

Abstract: Flash memory is accessed via mapping tables comprising a master mapping table and at least one secondary mapping table. The master mapping table contains indexes to the secondary mapping tables. The secondary mapping tables contain indexes to locations in the flash memory. The mapping tables are maintained in the flash memory. Upon initialization subsequent a safe power shutdown, the master mapping table is cached and secondary mapping tables are cached as needed. Upon initialization subsequent an unsafe power shutdown, the mapping tables are constructed in accordance with a multiple-phase process. In an example embodiment, the multiple-phase process comprises locating all the secondary mapping tables stored in the flash memory, determining which secondary mapping tables are valid, determining which secondary mapping tables are invalid, determining which sectors of the flash memory are free, and constructing the master mapping table and the secondary mapping tables from this information.

Abstract: Various flash management techniques may be described. An apparatus may comprise a processor, a flash memory coupled to the processor, and a flash management module. The flash management module may be executed by the processor to receive a write request to write data to the flash memory, write a first control sector with a sequence number to the flash memory, and write the sequence number, an address for a logical sector, and data to at least one physical sector corresponding to the logical sector of the flash memory. Other embodiments are described and claimed.

Abstract: Various flash management techniques may be described. An apparatus may comprise a processor, a flash memory coupled to the processor, and a flash management module. The flash management module may be executed by the processor to receive a write transaction request to write data to a flash memory, and write the data to a set of multiple discontiguous logical sectors corresponding to a set of physical sectors of the flash memory in a single atomic operation. Other embodiments are described and claimed.

Abstract: In one aspect, the present disclosure describes a process for maintaining file allocation tables (FATs) for a volume of storage medium. The process includes triggering, by a write operation, modification of data in an existing sector of a data file by writing of data to a new sector of the storage medium. The process also includes writing revised used/unused sector information into one FAT and setting a variable indicative of a number of FATs (NOF) to a first value. The process additionally includes copying the one FAT to another FAT and re-setting the variable to a second value.

Abstract: A system that determines where a particular XIP component is stored on a medium and loads the component into RAM for execution, providing the ability to demand page specific components at will from storage media, frees up working RAM on memory constrained devices. A Binary File System uses a generic block driver component that loads the XIP code from a block based storage medium. Features of the file system include the ability to load pre-“fixed up” components from a block based device. The invention thus allows an operating system to load code that was previously Executed In Place (XIP) from a block-oriented device.

Abstract: A system that determines where a particular XIP component is stored on a non-linearly addressable storage medium and loads the component into RAM for execution, providing the ability to demand page specific components at will from storage media, frees up working RAM on memory constrained devices. A Binary File System uses a generic block driver component that loads the XIP code from a block based storage medium. Features of the file system include the ability to load pre-“fixed up” components from a block based device. The invention thus allows an operating system to load code that was previously Executed In Place (XIP) from a block-oriented device.

Abstract: Concepts for enhancing operation of transaction-safe file allocation table systems are described. The concepts include writing a file to non-volatile memory media and rendering an update of file size to the TFAT storage medium; and receiving a request to locate data in a non-volatile memory having a TFAT file management system, selecting a sector of the memory to parse to locate the data, determining when the selected sector is a first sector of a directory or subdirectory of the memory and when determining reveals that the selected sector is a first sector, skipping reading data from the selected sector. The concepts also include flushing a cache and synchronizing FATs.

Abstract: A system that determines where a particular XIP component is stored on a medium and loads the component into RAM for execution, providing the ability to demand page specific components at will from storage media, frees up working RAM on memory constrained devices. A Binary File System uses a generic block driver component that loads the XIP code from a block based storage medium. Features of the file system include the ability to load pre-“fixed up” components from a block based device. The invention thus allows an operating system to load code that was previously Executed In Place (XIP) from a block-oriented device.

Abstract: In one aspect, the present disclosure describes a process for maintaining file allocation tables (FATs) for a volume of storage medium. The process includes triggering, by a write operation, modification of data in an existing sector of a data file by writing of data to a new sector of the storage medium. The process also includes writing revised used/unused sector information into one FAT and setting a variable indicative of a number of FATs (NOF) to a first value. The process additionally includes copying the one FAT to another FAT and re-setting the variable to a second value.

Abstract: Data capture and analysis for debugging embedded systems is disclosed. On a target, there is at least one data collector, each of which publishes predetermined data of the target, and a collection manager for managing the data collectors. On a host, there is at least one viewer, each of subscribes to the predetermined data of a data collector, for processing thereof, and a viewer manager for managing the viewers. Data collectors and viewers can be added, such that an extensible data capture and analysis embedded system architecture is provided.

Abstract: Target control abstraction for debugging embedded systems is disclosed. In an abstracted hardware model, there is a non-hardware-specific debugging interface, for communication between a debugger for the embedded system and the hardware of the embedded system. In an abstracted hardware-via-software model, there is a proxy to receive commands intended for the hardware of the embedded system from the debugger, and a component within a kernel of the embedded system to receive the commands and convey them to the hardware.