[Toybox] [CLEANUP] dd

[Isaac Dunham]

On Sat, May 03, 2014 at 11:16:14AM -0500, Rob Landley wrote:
> On 05/02/14 19:04, Isaac Dunham wrote:
> >> Nope: posix specifies "k" and "b", and that's it. This seems to have
> >> come from gnu, and busybox seems to have copied gnu, and this is just
> >> implementing what gnu did. Except busybox added "swab" last year, so the
> >> set of options this command is implementing is basically a snapshot of
> >> what busybox was doing at some point in the past.
> > 
> > Please also include mega (it's handy for writing disk images).
> 
> I have yet to actually bitch at the posix guys and ask them to fix their
> standards, but... ascii/ebcdic conversions? In their 2013 update to the
> 2008 spec? Really?

POSIX has a bad naming system: they lump a document with all the
corrections to various errata in something that's named as if it were a
new standard.
The equivalent would be if "Ubuntu 2015" were the same as Trusty Tahr
with all the bugfixes.

As far as I can tell, IBM and Apple are the only vendors who have
certified XPG4 conformance (XPG4 = SUSv4 = POSIX2008/POSIX2013).
Yes, I'm saying that as far as I can tell, even Solaris 11 goes no
further than UNIX 03.
So in a way, ebcdic makes sense...

<snip>
> If I could get a darn bsd box working with actual development
> environment (which means both "installs under qemu" and "package
> management system does not immediately flake out afterwards") that would
> be a good comparison point as well. I'd prefer a freebsd variant but if
> netbsd or openbsd or dragonfly or pcbsd are easier to get installed...

openbsd docs say that they don't support virtual environments.
pcbsd is freebsd with a few packages preinstalled.
dragonfly is a fork of freebsd 4.x aimed at optimal SMP performance.
mirbsd (you did not mention) is a 32-bit nosmp fork of openbsd; it's
mainly interesting for historical purposes.

So I'd say freebsd, netbsd, or dragonfly.
It will take a little bit of work setting up netbsd and pkgsrc (note
that the package management system is separate frm the OS!), but it's
more like a text-mode installer for Linux than what you ranted about
when trying PC-BSD.

netbsd claims that 
(1) qemu works with amd64, i386, and sparc/sparc64; the PPC ports have
not been tested in qemu, and arc (MIPS) sometimes will panic under heavy I/O.
There's also a guide for installing evbarm on qemu at
wiki.netbsd.org/ports/evbarm/qemu_arm/ ; this may take building from
source.  I'll note that netbsd can be cross-compiled to any target, and
I've heard of building it on Linux systems.
There's also a netbsd image of some vintage (no toolchain!) linked from
wiki.qemu.org/Testing (at nopid.free.fr/small.ffs.bz2 ).

(2) gxemul works with sh4, mips, arm, and ppc (ports:
mips=arc,cobalt,evbmips,hpcmips,pmax,sgimips arm=cats,evbarm,netwinder 
sh4=landisk ppc=macppc,prep)

<snip>
> >> (Why did busybox implement swab? The mailing list has somebody just
> >> submitting it out of the blue without actually explaining their use case
> >> for it. I'd think this option was on the obsolete side: the "nuxi"
> >> problem was fairly specific to 16 bit systems, 32 bit systems have the
> >> "xinu" problem instead. :)
> > 
> > Don't know why it was added, but openwrt backported it with this
> > justification:
> > Some boards have the WLAN EEPROM stored in flash in big-endian format, 
> > whereas the driver requires the EEPROM in little-endian format.
> > The conv=swab option in dd is particularly useful in this case.
> 
> Except it's conv=swab16 and there's no conv=swab32 or conv=swab64.
> That's the bit I don't understand. (I suppose I can _add_ a swab32.)
> 
> Or is all the hardware attached to busses that don't specify endianness
> in their wiring diagrams so old it's guaranteed to be a 16 bit bus?
> 
Not sure. I just found that explanation when I looked.

HTH,
Isaac Dunham

 1399164592.0