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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
