[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#345490: ITP: devio -- correctly read (or write) a region of a block device



Package: wnpp
Version: N/A; reported 2006-01-01
Severity: wishlist

Package name : devio
Version : 1.1
Upstream Author : John Bowler <jbowler@acm.org>
URL : http://devio.sourceforge.net/
License : MIT
Description : 

devio is a command line tool designed to read and write data to block
devices.  It allows random access to the device.  Read and write
operations occur in complete device blocks and are optimised to avoid a
write if the data has not changed. 

IO in devio is optimised for reading and writing sections of block
devices.  The main consideration is to restrict all accesses to the
device to whole device blocks aligned to a device block boundary. 
Standard stdio implementations do the same thing, however this is not
guaranteed by the stdio API.  In addition devio performs all write
operations as read-modify-write, with the write only being done if the
modify really changed some data.  This is important with flash (MTD)
devices where a write requires an erase and reduces the life of the
flash device.

devio write operations are fully synced, using the fdatasync(2) system
call, and fully checked for error conditions.

The byte reading and formatting support in the devio commands is
intended to facilitate operations where it is necessary to interpret
information contained within the device.  This frequently happens during
system bootstrap of embedded systems where the flash memory contains
important configuration data.

Examples of use can be found at
http://devio.sourceforge.net/devio-manual/example.htm

devio is used extensively in the NSLU2-Linux project
(http://www.nslu2-linux.org) to interact safely with the internal flash
memory of a running Linux system.  devio will be used in a future NSLU2
Debian kernel package postinst to install the new kernel into the
internal flash memory (which requires prepending some code to set the
machine id correctly, and byteswapping the little-endian arm kernel to
allow it to run from the RedBoot bootloader which sets up the device in
big-endian mode by default.

-- Rod Whitby (NSLU2-Linux Project Lead)



Reply to: