Implement /dev/byte (a generic byte source similiar to /dev/zero)
Subsystems (2)
cover Implement /dev/byte (a generic byte source similiar to /dev/zero)
Hello,
I don't know if this patch qualifies for inclusion into the mainline kernel, but maybe someone else would be interested in such, so I'm posting it here.
The main idea for that device was to have a source for 0xff to clear FLASH based devices. And to make it more generic, I've added the possibility to change the default value on a per file descriptor basis.
I don't want to discuss if such a device makes sense or if such should be done in userspace only. I like it as a device, otherwise I wouldn't have written it. So besides this message, I will not take part in such a discussion.
Regards,
Alexander Holler
PATCH 1/1 Implement /dev/byte (a generic byte source similiar to /dev/zero)
This device outputs by default 0xff instead 0 which makes more sense than 0 to clear e.g. FLASH based devices.
To make the device more general usable, the value it outputs is changeable on a per file descriptor basis through simple writes to it. Values can be decimal (0 - 255), octal (00 - 0377) or hex (0x0 - 0xff). For other values (or strings) written to it, the write operation returns an error and the subsequent output is undefined.
Usage examples:
# Fill /dev/sdX with 0xff.
dd </dev/byte of=/dev/sdX bs=4M
# Create a file of size 10GB and filled with 0xaa.
exec 5<>/dev/byte # Open /dev/byte and assign fd 5 to it
echo 0xaa >&5 # Instruct the device to output 0xaa
dd <&5 of=foo.img bs=10M count=1024 # create and fill the file
exec 5>&- # Close fd 5
--- Documentation/byte.txt | 24 +++++++++++ Documentation/devices.txt | 1 + drivers/char/Kconfig | 10 ++++ drivers/char/mem.c | 101 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 136 insertions(+), 0 deletions(-) create mode 100644 Documentation/byte.txt
Documentation/byte.txt new file +24 -0
@@ -0,0 +1,24 @@ +/dev/byte is a generic byte source (similiar to /dev/zero) which uses +0xff as the default value. + +The idea was to have a source for 0xff to erase FLASH based devices like +SSDs and SD-Cards for which 0xff makes more sense than 0. + +To make the device more general usable, the value it outputs is changeable +on a per file descriptor basis through simple writes to it. +Values can be decimal (0 - 255), octal (00 - 0377) or hex (0x0 - 0xff). +For other values (or strings) written to it, the write operation returns an +error and the subsequent output is undefined. + +Usage examples: + +# Fill /dev/sdX with 0xff. +dd </dev/byte of=/dev/sdX bs=4M + +# Create a file of size 10GB and filled with 0xaa. +exec 5<>/dev/byte # Open /dev/byte and assign fd 5 to it +echo 0xaa >&5 # Instruct the device to output 0xaa +dd <&5 of=foo.img bs=10M count=1024 # create and fill the file +exec 5>&- # Close fd 5 + +Apr 2011, Alexander Holler <[email protected]>
Documentation/devices.txt +1 -0
@@ -101,6 +101,7 @@ Your cooperation is appreciated. 11 = /dev/kmsg Writes to this come out as printk's 12 = /dev/oldmem Used by crashdump kernels to access the memory of the kernel that crashed. + 13 = /dev/byte Generic byte source (default 0xff). 1 block RAM disk 0 = /dev/ram0 First RAM disk
drivers/char/Kconfig +10 -0
@@ -97,6 +97,16 @@ config DEVKMEM kind of kernel debugging operations. When in doubt, say "N". +config DEV_BYTE + bool "/dev/byte virtual device support" + default y + help + Say Y here if you want to support the /dev/byte device. The + /dev/byte device is a generic byte source (similiar to /dev/zero), + but uses 0xff as a default value which is changeable on a per + file descriptor basis. + Read <file:Documentation/byte.txt> for a usage description. + config BFIN_JTAG_COMM tristate "Blackfin JTAG Communication" depends on BLACKFIN
drivers/char/mem.c +101 -0
131 lines not on this page · raw message
Signature · 1 line
1.7.3.4
Quoted 2 lines · Alexander Holler
This device outputs by default
0xffinstead 0 which makes more sense than 0 to clear e.g. FLASH based devices.
Well, now you should provide example where you mmap /dev/byte, then write() the flash directly from the mapping.
... hmm, that brings good question: what happens on existing mappings when the byte is changed?
Quoted 5 lines
To make the device more general usable, the value it outputs is changeable on a per file descriptor basis through simple writes to it. Values can be decimal (0 - 255), octal (00 - 0377) or hex (
0x0-0xff). For other values (or strings) written to it, the write operation returns an error and the subsequent output is undefined.
...
Quoted 3 lines
# Create a file of size 10GB and filled with
0xaa.
exec 5<>/dev/byte # Open/dev/byteand assign fd 5 to it
echo0xaa>&5 # Instruct the device to output0xaa
That's seriously strange. /dev/byte should be changeable... by writing bytes.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Am 20.04.2011 12:57, schrieb Pavel Machek:
Quoted 9 lines · Alexander Holler
Quoted 2 lines
This device outputs by default
0xffinstead 0 which makes more sense than 0 to clear e.g. FLASH based devices.Well, now you should provide example where you mmap
/dev/byte, thenwrite()the flash directly from the mapping.... hmm, that brings good question: what happens on existing mappings when the byte is changed?
I never used mmap (never had a need to use it) explicit and barely know what it does. And I don't see a reason to use mmap on /dev/byte. Otherwise I would have known before the reason why /dev/zero exists. ;)
So I can't answer what happens when someone uses mmap on /dev/byte and changes the value while the map exists (without testing it by myself).
Quoted 5 lines
Quoted 5 lines
To make the device more general usable, the value it outputs is changeable on a per file descriptor basis through simple writes to it. Values can be decimal (0 - 255), octal (00 - 0377) or hex (
0x0-0xff). For other values (or strings) written to it, the write operation returns an error and the subsequent output is undefined.
Quoted 7 lines
...
Quoted 3 lines
# Create a file of size 10GB and filled with
0xaa.
exec 5<>/dev/byte # Open/dev/byteand assign fd 5 to it
echo 0xaa>&5 # Instruct the device to output0xaaThat's seriously strange.
/dev/byteshould be changeable... by writing bytes.
As I've written before, that was the only solution I could come up with which makes it possible to change the output of /dev/byte on the fly without introducing race conditions (except ioctl). I know, it's ugly, but works, at least for common (read) file operations.
So it seems the only proper solution would be to use minors which would make such a device static.
So I better stick to something in userland, even when I would like to have at least /dev/byteFF. Chances seem to be minimal to get such included in the kernel if no one else sees a usage pattern for such.
Regards,
Alexander
Quoted 10 lines · Alexander Holler
I don't know if this patch qualifies for inclusion into the mainline kernel, but maybe someone else would be interested in such, so I'm posting it here.
The main idea for that device was to have a source for
0xffto clear FLASH based devices. And to make it more generic, I've added the possibility to change the default value on a per file descriptor basis.I don't want to discuss if such a device makes sense or if such should be done in userspace only. I like it as a device, otherwise I wouldn't have written it. So besides this message, I will not take part in such a discussion.
cant you do this with cuse ? that would satisfy the "has to be a device" requirement while keeping it in userspace.
although, i have a hard time seeing there be a realistic perf diff with:
tr '\000' '\377' < /dev/zero | dd ......
-mike
Am 18.04.2011 15:57, schrieb Mike Frysinger:
Quoted 8 lines · Alexander Holler
Quoted 7 lines
I don't know if this patch qualifies for inclusion into the mainline kernel, but maybe someone else would be interested in such, so I'm posting it here.
The main idea for that device was to have a source for
0xffto clear FLASH based devices. And to make it more generic, I've added the possibility to change the default value on a per file descriptor basis.
Quoted 6 lines
Quoted 3 lines
I don't want to discuss if such a device makes sense or if such should be done in userspace only. I like it as a device, otherwise I wouldn't have written it. So besides this message, I will not take part in such a discussion.
cant you do this with cuse ? that would satisfy the "has to be a device" requirement while keeping it in userspace.
I know almost nothing about cuse, but I assume it should be possible to build such a device with cuse too.
Quoted 2 lines
although, i have a hard time seeing there be a realistic perf diff with:
tr '\000' '\377'</dev/zero| dd ......
There are many other ways to achieve such in userspace (even without using /dev/zero) and I want to avoid such a discussion.
As for /dev/zero there are many other possible reasons to use such a device, besides filling something with a value. For me it's as reasonable as dev/zero, just that it offers a bit more flexibility and provides another, at least for me useful, default value. Maybe /dev/nzero would have been a good name too. ;)
But I don't really care about inclusion into the kernel, it's just something I had lying around (and needed only marginally work to finalize as a proper patch) and I thought someone else could find it usefull and I should share that here.
Regards,
Alexander Holler
Quoted 5 lines
As for
/dev/zerothere are many other possible reasons to use such a device, besides filling something with a value. For me it's as reasonable as dev/zero, just that it offers a bit more flexibility and provides another, at least for me useful, default value. Maybe/dev/nzerowould have been a good name too. ;)
/dev/zero exists not to put \0's into files as such but because it is very useful to be able to map the zero page (a read only, or copy-on-write blank page) into programs. The mmap is the reason it is there.
Quoted 4 lines
But I don't really care about inclusion into the kernel, it's just something I had lying around (and needed only marginally work to finalize as a proper patch) and I thought someone else could find it usefull and I should share that here.
Implementationwise I think I would have gone for allocating a new device and range of 256 minors - that would avoid the funky stuff setting what it fills with as you'd just fill with the minor number.
Alan
Hello,
Am 19.04.2011 10:44, schrieb Alan Cox:
Quoted 10 lines
Quoted 5 lines
As for
/dev/zerothere are many other possible reasons to use such a device, besides filling something with a value. For me it's as reasonable as dev/zero, just that it offers a bit more flexibility and provides another, at least for me useful, default value. Maybe/dev/nzerowould have been a good name too. ;)
/dev/zeroexists not to put \0's into files as such but because it is very useful to be able to map the zero page (a read only, or copy-on-write blank page) into programs. The mmap is the reason it is there.
Thanks for the explanation.
Quoted 8 lines
Quoted 4 lines
But I don't really care about inclusion into the kernel, it's just something I had lying around (and needed only marginally work to finalize as a proper patch) and I thought someone else could find it usefull and I should share that here.
Implementationwise I think I would have gone for allocating a new device and range of 256 minors - that would avoid the funky stuff setting what it fills with as you'd just fill with the minor number.
I thought about that too, but that would have been to easy (and static). ;)
And the usage of file descriptors was the only idea I've come up with, which is multitasking and multiuser aware.
Regards,
Alexander
Hello,
Am 19.04.2011 11:05, schrieb Alexander Holler:
Quoted 8 lines
Quoted 3 lines
Implementationwise I think I would have gone for allocating a new device and range of 256 minors - that would avoid the funky stuff setting what it fills with as you'd just fill with the minor number.
I thought about that too, but that would have been to easy (and static). ;)
And the usage of file descriptors was the only idea I've come up with, which is multitasking and multiuser aware.
If I add the possibility to use minors to set the default value (but still leave the possibility to change the default dynamically), would that raise the chance to become included? ;)
Regards,
Alexander