Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Thu, 1 May 2014, Eitan Adler wrote:
On 1 May 2014 09:59, Jung-uk Kim j...@freebsd.org wrote:
On 2014-04-30 15:38:18 -0400, ?? wrote:
On 2014-04-30 02:20:48 -0400, ?? wrote:
Mail clients keep getting worse. Fitst the apostrophes were corrupted,
now the names...
Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision:
265132 URL: http://svnweb.freebsd.org/changeset/base/265132
Log: Add a /dev/full device.
/dev/full is similar to /dev/zero except it always returns ENOSPC
when you attempt to write to it.
Reviewed by: jhibbits Discussed with:rpaulo
... Please see lindev(4).
I guess I wasn't loud enough. We already had the exact same feature
via lindev(4). In fact, now it panics if we load both, i.e.,
make_dev_credv: bad si_name (error=17, si_name=full). Please see
sys/dev/lindev/full.c. Also, the manual page is still symlinked from
lindev.4.
Thanks for letting me know about lindev(4). I've brought up /dev/full
to a few people and no one else mentioned it. Since /dev/full is not
linux specific and code/binary size addition is minor I've opted to
just remove lindev and leave my implementation.
It seems reasonable to have it unconditional, since it is so small when
it is not a separate module.
Please merge any better style from lindev to null.c. I only noticed a
couple of remaining style bugs in the new code in null.c. There are
a few more in old code in null.c. lindev has about the same density
of style bugs:
full.c:
% /* ARGSUSED */
The __unused annotations are ugly enough. lint has been unusable for
a long time.
% static int
% full_read(struct cdev *dev __unused, struct uio *uio, int flags __unused)
% {
% int error = 0;
Initialization in declaration.
%
% while (uio-uio_resid 0 error == 0)
% error = uiomove(zbuf, MIN(uio-uio_resid, PAGE_SIZE), uio);
Use of the MIN() macro. MIN() was removed from the kernel in 4.4BSD, but
was restored in FreeBSD to allow broken code that uses it to work.
The min() family of inline functions is supposed to be used in 4.4BSD and
later. It is still used a lot. However, it is broken as designed since
it is type-specific and thus is especially hard to use with typedefed types
like typeof(uio-uio_resid). MIN() has smaller design errors. The correct
API is a type-generic version of min(). Unfortunately, the good name min()
is already used (it means take the minimum of u_int values).
%
Extra blank line.
% return (error);
% }
%
% /* ARGSUSED */
As above.
% static int
% full_write(struct cdev *dev __unused, struct uio *uio __unused,
% int flags __unused)
% {
%
This blank line is not extra, but is perfectly ugly to style(9) spec.
% return (ENOSPC);
% }
%
% /* ARGSUSED */
% int
% lindev_modevent_full(module_t mod __unused, int type, void *data __unused)
% {
%
% switch(type) {
% case MOD_LOAD:
% zbuf = (void *)malloc(PAGE_SIZE, M_TEMP, M_WAITOK | M_ZERO);
Bogus cast. Has no effect. This is not C++.
% full_dev = make_dev(full_cdevsw, 0, UID_ROOT, GID_WHEEL,
% 0666, full);
% if (bootverbose)
% printf(full: full device\n);
I don't like hiding this under bootverbose. 1 line per device is not much
spam.
% break;
%
I don't like the style of an extra blank line for each case in a switch.
This style is normal in the kernel, but is not permitted by style(9)
(because the example in style(9) doesn't use it). Fully ugly versions
of this style put the extra blank line before each case statement. This
switch statement is missing the extra blank line before the first case
statement.
null.c does this inconsistently. It uses the extra blank line for the
switch statement in null_modevent(), but not for any other switch
statement in the file. indent(1) has no chance of preserving such
differences.
% case MOD_UNLOAD:
% destroy_dev(full_dev);
% free(zbuf, M_TEMP);
% break;
%
% case MOD_SHUTDOWN:
% break;
%
% default:
% return (EOPNOTSUPP);
% }
%
Extra blank line.
% return (0);
% }
lindev.c:
% ...
% /*
% * lindev is supposed to be a collection of linux-specific devices
% * that we also support, just not by default.
% * While currently there is only /dev/full, we are planning to see
% * more in the future.
% * This file is only the container to load/unload all supported devices;
% * the implementation of each should go into its own file.
% */
There is only dev/full in lindev now.
I don't like having lots of little files supporting 1 feature each or 1
feature across 3 files. After removing lindev/full.c but not all of
lindev, the 2 remaining files support 0 features. Removing all of
lindev would break adding more features, if any.
% /* ARGSUSED */
% static int
% lindev_modevent(module_t mod, int type, void *data)
Here there is useless lint markup, but no useful compiler markup
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-04-30 15:38:18 -0400, ?? wrote: On 2014-04-30 02:20:48 -0400, ?? wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. Reviewed by: jhibbits Discussed with:rpaulo ... Please see lindev(4). I guess I wasn't loud enough. We already had the exact same feature via lindev(4). In fact, now it panics if we load both, i.e., make_dev_credv: bad si_name (error=17, si_name=full). Please see sys/dev/lindev/full.c. Also, the manual page is still symlinked from lindev.4. % grep -n 'full\.4' share/man/man4/Makefile 822:MLINKS+=lindev.4 full.4 If we're really making it a standard feature, then lindev must be removed (or at least disconnected from build), __FreeBSD_version must be bumped, and a new UPDATING entry for the change is required. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTYn2MAAoJEHyflib82/FGDW0H+wUW91tsvm3jwzn736MmM3R/ jyBKP6HBiUYfpF9tIQQMcnoGq1+xsWBJfRzn1sK3IdFUaP9R0HFwAz2IEpGQ4Lsy SeincVpI+T5FkSiZhnWYke4W3XsCg2JAeUKVbSg6u9SgxE3RTGdYBmHwSfHOEGYn Q3kqSAjq44F7jJRl2DNyo1AT8/IYfws2IrEM5vakfry/iRrMKEMt7ICCKK3v1TA8 dJoTxoM3aW9NQFvk1vPe6s4TVQEpnuWhoadRCuUQtZQ7skoONpmXNObWwCyoWbq5 zUjtEea60bXXMEo84ruVN/3hCHZqRAXiWhYMTf3cg1QirV9upshP0IOSaGo/Q4o= =drUB -END PGP SIGNATURE- ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On 1 May 2014 09:59, Jung-uk Kim j...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-04-30 15:38:18 -0400, ?? wrote: On 2014-04-30 02:20:48 -0400, ?? wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. Reviewed by: jhibbits Discussed with:rpaulo ... Please see lindev(4). I guess I wasn't loud enough. We already had the exact same feature via lindev(4). In fact, now it panics if we load both, i.e., make_dev_credv: bad si_name (error=17, si_name=full). Please see sys/dev/lindev/full.c. Also, the manual page is still symlinked from lindev.4. Thanks for letting me know about lindev(4). I've brought up /dev/full to a few people and no one else mentioned it. Since /dev/full is not linux specific and code/binary size addition is minor I've opted to just remove lindev and leave my implementation. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r265132 - in head: share/man/man4 sys/dev/null
Author: eadler
Date: Wed Apr 30 06:20:48 2014
New Revision: 265132
URL: http://svnweb.freebsd.org/changeset/base/265132
Log:
Add a /dev/full device.
/dev/full is similar to /dev/zero except it always returns
ENOSPC when you attempt to write to it.
Reviewed by: jhibbits
Discussed with: rpaulo
Added:
head/share/man/man4/full.4 (contents, props changed)
Modified:
head/share/man/man4/null.4
head/share/man/man4/zero.4
head/sys/dev/null/null.c
Added: head/share/man/man4/full.4
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/share/man/man4/full.4 Wed Apr 30 06:20:48 2014(r265132)
@@ -0,0 +1,47 @@
+.\ Copyright (c) 2014
+.\Eitan Adler ead...@freebsd.org. All rights reserved.
+.\
+.\ Redistribution and use in source and binary forms, with or without
+.\ modification, are permitted provided that the following conditions
+.\ are met:
+.\ 1. Redistributions of source code must retain the above copyright
+.\notice, this list of conditions and the following disclaimer.
+.\ 2. Redistributions in binary form must reproduce the above copyright
+.\notice, this list of conditions and the following disclaimer in the
+.\documentation and/or other materials provided with the distribution.
+.\
+.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+.\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\ SUCH DAMAGE.
+.\
+.\ $FreeBSD$
+.\
+.Dd March 29, 2014
+.Dt FULL 4
+.Os
+.Sh NAME
+.Nm full
+.Nd the full device
+.Sh DESCRIPTION
+The
+.Nm
+device supplies an endless stream of zeros when read.
+However, it will always be full when writing to it.
+.Sh FILES
+.Bl -tag -width /dev/full
+.It Pa /dev/full
+.El
+.Sh SEE ALSO
+.Xr null 4
+.Xr zero 4
+.Sh Author
+This device and man page was written by
+.An Eitan Adler Aq ead...@freebsd.org .
Modified: head/share/man/man4/null.4
==
--- head/share/man/man4/null.4 Wed Apr 30 06:03:01 2014(r265131)
+++ head/share/man/man4/null.4 Wed Apr 30 06:20:48 2014(r265132)
@@ -48,6 +48,7 @@ device is always zero.
.It Pa /dev/null
.El
.Sh SEE ALSO
+.Xr full 4
.Xr zero 4
.Sh HISTORY
A
Modified: head/share/man/man4/zero.4
==
--- head/share/man/man4/zero.4 Wed Apr 30 06:03:01 2014(r265131)
+++ head/share/man/man4/zero.4 Wed Apr 30 06:20:48 2014(r265132)
@@ -49,6 +49,7 @@ supply of null bytes when read.
.It Pa /dev/zero
.El
.Sh SEE ALSO
+.Xr full 4
.Xr null 4
.Sh HISTORY
A
Modified: head/sys/dev/null/null.c
==
--- head/sys/dev/null/null.cWed Apr 30 06:03:01 2014(r265131)
+++ head/sys/dev/null/null.cWed Apr 30 06:20:48 2014(r265132)
@@ -1,6 +1,7 @@
/*-
* Copyright (c) 2000 Mark R. V. Murray Jeroen C. van Gelderen
* Copyright (c) 2001-2004 Mark R. V. Murray
+ * Copyright (c) 2014 Eitan Adler
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -47,7 +48,9 @@ __FBSDID($FreeBSD$);
/* For use with destroy_dev(9). */
static struct cdev *null_dev;
static struct cdev *zero_dev;
+static struct cdev *full_dev;
+static d_write_t full_write;
static d_write_t null_write;
static d_ioctl_t null_ioctl;
static d_ioctl_t zero_ioctl;
@@ -70,6 +73,23 @@ static struct cdevsw zero_cdevsw = {
.d_flags = D_MMAP_ANON,
};
+static struct cdevsw full_cdevsw = {
+ .d_version =D_VERSION,
+ .d_read = zero_read,
+ .d_write = full_write,
+ .d_ioctl = zero_ioctl,
+ .d_name = full,
+};
+
+
+/* ARGSUSED */
+static int
+full_write(struct cdev *dev __unused, struct uio *uio, int flags __unused)
+{
+
+ return (ENOSPC);
+}
+
/* ARGSUSED */
static int
null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused)
@@ -155,7 +175,9 @@ null_modevent(module_t mod __unused, int
switch(type) {
case MOD_LOAD:
if (bootverbose)
- printf(null: null device, zero device\n);
+ printf(null: full device, null device,
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Wed, Apr 30, 2014 at 7:48 AM, Ian Lepore i...@freebsd.org wrote: On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. dd if=/dev/zero | tr \000 \377 | dd of=xxx But it's not quite the same. Cheers, matthew ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
- Original Message - From: Ian Lepore i...@freebsd.org To: Eitan Adler ead...@freebsd.org Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-head@FreeBSD.org Sent: Wednesday, April 30, 2014 3:48 PM Subject: Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. Surely for that you want camcontrol security ...? Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Wed, 2014-04-30 at 17:22 +0100, Steven Hartland wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Eitan Adler ead...@freebsd.org Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-head@FreeBSD.org Sent: Wednesday, April 30, 2014 3:48 PM Subject: Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. Surely for that you want camcontrol security ...? Regards Steve I have no idea what that is, but given that it has security in the name, it's almost certainly NOT what I want in any way shape or form. Shocking as it may be, some people are just not obsessed with security, for good reason. It just isn't a consideration in any way in my day to day activities. When I want to make an sdcard, or some portion thereof, look empty/virgin/new-from-factory for testing on an embedded system, that has nothing to do with security, and everything to do with just exactly what I asked for: something that writes all-ones-bits. Besides, cam and sdcards don't play in the same sandboxes. -- Ian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
- Original Message - From: Ian Lepore i...@freebsd.org To: Steven Hartland kill...@multiplay.co.uk Cc: Eitan Adler ead...@freebsd.org; src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-head@FreeBSD.org Sent: Wednesday, April 30, 2014 6:13 PM Subject: Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null On Wed, 2014-04-30 at 17:22 +0100, Steven Hartland wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Eitan Adler ead...@freebsd.org Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-head@FreeBSD.org Sent: Wednesday, April 30, 2014 3:48 PM Subject: Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. Surely for that you want camcontrol security ...? Regards Steve I have no idea what that is, but given that it has security in the name, it's almost certainly NOT what I want in any way shape or form. Shocking as it may be, some people are just not obsessed with security, for good reason. It just isn't a consideration in any way in my day to day activities. Its a standard option which allows you to erase the contents of a device its named security as thats the class of the ATA commands which provides this functionality. When I want to make an sdcard, or some portion thereof, look empty/virgin/new-from-factory for testing on an embedded system, that has nothing to do with security, and everything to do with just exactly what I asked for: something that writes all-ones-bits. That does kind of describe the functionality thats provided by camcontrol security appart from it explicity asks for the cells to be erased, so results in the device being as close to from factory as possible but, not set to a specific value. Maybe thats the difference between ATA based flash media e.g. SSD and sdcard's? Regards Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On 2014-04-30 02:20:48 -0400, ?? wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. Reviewed by:jhibbits Discussed with: rpaulo ... Please see lindev(4). Jung-uk Kim ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Apr 30, 2014, at 11:13 AM, Ian Lepore i...@freebsd.org wrote: On Wed, 2014-04-30 at 17:22 +0100, Steven Hartland wrote: - Original Message - From: Ian Lepore i...@freebsd.org To: Eitan Adler ead...@freebsd.org Cc: src-committ...@freebsd.org; svn-src-...@freebsd.org; svn-src-head@FreeBSD.org Sent: Wednesday, April 30, 2014 3:48 PM Subject: Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null On Wed, 2014-04-30 at 06:20 +, Eitan Adler wrote: Author: eadler Date: Wed Apr 30 06:20:48 2014 New Revision: 265132 URL: http://svnweb.freebsd.org/changeset/base/265132 Log: Add a /dev/full device. /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. Surely for that you want camcontrol security ...? Regards Steve I have no idea what that is, but given that it has security in the name, it's almost certainly NOT what I want in any way shape or form. Shocking as it may be, some people are just not obsessed with security, for good reason. It just isn't a consideration in any way in my day to day activities. When I want to make an sdcard, or some portion thereof, look empty/virgin/new-from-factory for testing on an embedded system, that has nothing to do with security, and everything to do with just exactly what I asked for: something that writes all-ones-bits. Besides, cam and sdcards don't play in the same sandboxes. You likely want some variation of the SATA secure erase command, which despite having the name ‘secure’ in it really is a ‘erase all contents of this drive and reinitialize to factory defaults’. Warner ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On 1 May 2014, at 0:18, Ian Lepore i...@freebsd.org wrote: /dev/full is similar to /dev/zero except it always returns ENOSPC when you attempt to write to it. For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/79421 :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r265132 - in head: share/man/man4 sys/dev/null
On Wed, 30 Apr 2014, Matthew Fleming wrote: On Wed, Apr 30, 2014 at 7:48 AM, Ian Lepore i...@freebsd.org wrote: For some reason this reminded me of something I've been wanting for a while but never get around to writing... /dev/ones, it's just like /dev/zero except it returns 0xff bytes. Useful for dd'ing to wipe out flash-based media. dd if=/dev/zero | tr \000 \377 | dd of=xxx Why all these processes and i/o's? tr /dev/dev/zero \000 \377 The dd's may be needed for controlling the block sizes. But it's not quite the same. It is better, since it is not limited to 0xff bytes :-). Oops, perhaps not. tr not only uses stdio to pessimize the i/o; it uses wide characters 1 at a time. It used to use only characters 1 at a time. yes(1) is limited to newline bytes, or newlines mixed with strings. It also uses stdio to pessimize the i/o, but not wide characters yet. stdio's pessimizations begin with naively believing that st_blksize gives a good i/o size. For most non-regular files, including all (?) devices and all (?) pipes, st_blksize is PAGE_SIZE. For disks, this has been broken signficantly since FreeBSD-4 where it was the disk's si_bsize_best (usually 64K). For pipes, this has been broken significantly since FreeBSD-4 where it was pipe_buffer.size (either PIPE_SIZE = 16K or BIG_PIPE_SIZE = 64K). So standard utilities tend to be too slow to use on disks. You have to use dd and relatively complicated pipelines to get adequate block sizes. Sometimes dd or a special utility is needed to get adequate control and error handling. I have such a special utility for copying disks with bad sectors, but prefer to use just cp fpr copying disks. cp doesn't use stdio, and doesn't use mmap() above certain small size; it uses read/write() with a fixed block size of 64K or maybe larger in -current, so it works OK for copying disks. The most broken utilities that I use often for disk devices are: - md5. This (really libmd/mdXhl.c) has been broken on all devices (really on all non-regular files) since ~2001. It is broken by misusing st_size instead of by trusting st_blksize. st_size is only valid for regular files, but is used on other file types to break them. For example: pts/21:bde@freefall:~ md5 /dev/null MD5 (/dev/null) = d41d8cd98f00b204e9800998ecf8427e pts/21:bde@freefall:~ md5 /dev/zero MD5 (/dev/zero) = d41d8cd98f00b204e9800998ecf8427e Similarly for disk devices. All devices are seen as empty by md5. The workaround is to use a pipeline, or just stdin. cat /dev/zero | md5 and even md5 /dev/zero confuse md5 into using a different input method that works. OTOH, md5 /dev/fd/0 sees an empty device file, and cat /dev/zero | md5 /dev/fd/0 fails immediately with a seek error. Pipes have st_size == 0 too, so the input method that stats the file would see an empty file too, so it must not be reached in the working case. md5 /dev/fd/0 apparently just stats the device file, and this appears to be empty. I'm not sure if it is the tty device file or /dev/fd/0 that is seen. cat /dev/zero | md5 /dev/fd/0 apparently reaches the buggy code, but somehow gets further and fails trying to seek. To get adequate block sizes for disks, use dd in the pipeline that must be used for other reasons. I only recently noticed that pipes have st_blksize = PAGE_SIZE, so that if you pipe to stdio utilities then the i/o will be pessimized and reblocking using another dd in a pipeline to get back to an adequate size. PAGE_SIZE is large enough to not be very pessimal for some uses. - cmp. cmp uses mmap() excessively for regular files, but for device files it uses per-char stdio excessively. ( More on md5. The i/o routine for the working is are in the application (md5/md5.c). This uses fread() with the bad block size BUFSIZ. This is still 1024. It is more broken than st_blksize. However, fread() is not per-char, so it is reasonably efficient. stdio uses st_blksize for read() from the file. When the file is regular, the block size is again relatively unimportant provided the file system has a large enough block size or does clustering. For device files, clustering might occur at levels below the file system, but usually doesn't for disks. Instead, small i/o's get relatively slower with time except on high-end SSDs with high transactions per second, because clustering at low levels takes too many transactions. The i/o routine for the non0-working case is in the library (libmd/mdXhl.c). It uses read(), but with the silly stdio block size of BUFSIZ. libmd files have several includes of stdio.h, but don't seem to use stdio except for bugs like this. The result is that the i/o is especially pessimized for the usual regular file case. Buffering in the kernel limits this pessimization. ) The device file case for cmp just uses getc()/putc(). This first gets the st_blksize pessimization. Then it gets
