On Mon, Aug 17, 2015 at 11:57 AM, Rob Landley <[email protected]> wrote: > On 08/16/2015 06:31 PM, Isaac Dunham wrote: >> On Sat, Aug 15, 2015 at 09:41:03AM -0500, Rob Landley wrote: >>> On 08/14/2015 07:51 PM, enh wrote: >>>> iftop >>>> ioctl >>>> lsof >>>> prlimit >>>> -- will rewrite these at some point. turns out there's an existing >>>> prlimit with a much friendlier command-line than ours >>>> (http://man7.org/linux/man-pages/man1/prlimit.1.html). >>> >>> I have part of an lsof here I could take a stab at finishing. The >>> problem is the lsof man page is 2700 lines long and I dunno what a sane >>> subset of this would be. (Suggestions and/or test cases welcome...) >> >> lsof has 37 options, so it's not even possible to set that many optflags. > > If absolutely necessary I can change optflags to 64 bit. I just had it > forced 32 bit instead of "long" so nobody would accidentally use more > and not noticed because they only tested on 64 bit. > > For a while I was trying to avoid 64 bit ints on 32 bit platforms > because gcc/libgcc code for doing that is so awful. But I think we're > finally a single digit number of years away from 64 bit becoming the > baseline even for embedded, and 32 bit going the way of 16 bit. (That > single digit is most likely a 9, but still...) > > (Ok, x32 and friends may be involved. Defaulting to 32 bit on 64 bit > targets to save space is what sparc and powerpc did for years, using a > 32 bit address space within a 64 bit OS to keep stack size and function > argument passing down to a dull roar. But the availability of 64 bit > registers in these contexts means you don't need the horrible libgcc > glue code.) > > Predictions are hard, especially about the future. > >> (Of those, 10 also have a variant that starts with "+" rather than "-".) > > I've dealt with that before (it's why the numberic - type went in), and > the non-numeric version comes up in a few other places like stty. I'll > need to do a design extension of lib/args.c to handle that, not sure > what it should look like yet... > > So yeah, a thing, needs to be done, requires new infrastructure. Oh well. > >> Busybox implements only the minimum (lsof with no arguments or options). >> I'd find the following useful: >> * the optional [NAMES...] argument, which restricts the open files displayed >> to a list of filenames. >> * the following options: >> -l turns off username/group lookup for display >> -u FOO restricts processes examined to a specified user or list of users >> -p PIDS only examine processes in the comma-separated list of PIDs >> (also accepts a "^" operator to exclude a specific PID) > > Good to know.
Android's lsof only supported -p (though it didn't use that syntax). host-based scripts in the Android tree use -t. > I've used lsof to find ipv4 ports. (What's the server running on port 80 > on this box, what are all open ports on this box...) > >>> The ioctl command hasn't got a man page in ubuntu, and when I type it at >>> the command line it doesn't even suggest a package to install. >>> Unfortunately, my macbuntu image hasn't got aosp installed on it, and >>> when I tried to follow the instructions apt-get prompted me to uninstall >>> various 64 bit packages so it could install the 32 bit versions. When I >>> tried to install it in a fresh VM last weekend it ran out of space (30 >>> gigs is not enough for Ubuntu+AOSP, apparently) so I need to install >>> another fresh VM image with more space and try again... >> >> It's an android-specific command, and there's a port to standard Linux >> here: >> www.ccs.neu.edu/home/bchafy/androidioctl/androidioctl.html > > I'll take a look, thanks. > >>>> log >>>> nandread >>>> newfs_msdos >>>> uptime >>>> -- ??? >>> >>> I think uptime's good? (Matches ubuntu, anyway.) >> >> But not android. > > Ah, I have a note about that in the todo list. (Down in the compost heap > part of it...) > > Right, the design issue was implementing -a and -l command line options > for the different output formats, and checking CFG_TOYBOX_ON_ANDROID to > determine which one to default to in a given build environment, and > whether that was just too disgusting for words or what. :) i think first we should just fix uptime.c to build on Android (patch sent earlier today) and see if anyone actually cares about the traditional Android output. if not (and i suspect they won't), job done. if they do, we can worry about it then. >>> mkfs.vfat isn't that big of a todo item, I should just do it. (It's got >>> some strange corner cases but I think I have them all listed now. I'm >>> _tempted_ to do mtools, and a mke2fs/mksquashfs/mkisofs equivalent for >>> vfat, which is where it all turns into a Big Thing and gets shelved >>> again, but I can do that later.) >> >> Note that newfs_msdos, which Android and the BSDs use, is functionally >> equivalent but uses a completely different syntax: >> mkfs.vfat newfs_msdos >> -n -L LABEL >> -F -a FAT size (12/16/32) >> -B Bootloader (file to use) >> -O OEM string >> -h number of hidden sectors >> -f -n Number of FATs >> -k -b Backup FAT sector (FAT32) >> ... > > Yup, but having two aliases with different command lines for the same > basic plumbing is fairly straightforward. :) > >> The OEM should be 3+ uppercase, padded to 5 chars with spaces, then >> [0-9].[0-9] >> This is not required for correctness, but MSDOS and some versions of >> Windows are picky about it (can result in complete data loss upon >> disk insertion). > > *blink* *blink* > > What? > > I... > > What? it's even worse than that already sounds. the spec says that ' ' isn't allowed. BSD switched to using '_', which i think was how we know that there are some very fussy implementations out there. >> [snip] >>> Meanwhile the set of things I'm attacking right now are mostly in the >>> status page's "development" target: >>> >>> http://landley.net/toybox/status.html#development >>> >>> That's so I can replace the rest of busybox in aboriginal linux. (It's >>> what I've got a real world data regression test harness for.) >>> >>> Once I've got that building linux from scratch without busybox, my >>> _next_ target is to try to get it building AOSP. Which is likely to be >>> _so_ much fun. (On the bright side, a panel I attended at Linuxcon Japan >>> may have given me enough info to write a git tool capable of satisfying >>> repo's needs, although it's still a big command to write and the first >>> pass would be download-only. Still, one more chunk of a self-hosting >>> build environment...) >>> >>> Actually before I do _that_ I need to tackle the libc can of worms >>> (migrate aboriginal off of uClibc to musl for the supported targets, >>> which is currently blocked by my Linux From Scratch 6.8 regression test >>> having more than one package with an if/else staircase of libcs it >>> recognizes with an #error at the end), and then extract bionic from the >>> AOSP build (nontrivial) and see if I can build aboriginal with that and >>> how the native build environment behaves under it (probably not pretty)... >> >> Here, I think that a later version of LFS should help: >> several packages have been fixed to work properly with musl since then. >> LFS 6.8 is basically a snapshot of Linux as it was before musl became >> useful, back when Android support was frequently missing...you get >> the picture. > > Yup. I've been meaning to upgrade it to at least 7.4 (which had a > corresponding BLFS 7.4 release, the first in _ages_) for quite a while > now. It's just a largeish redo and adding a second BLFS image consuming > the LFS output puts it into can of worms territory. (I don't _need_ to > do that, but it's a momentum thing...) > > The other can-of-worms thing is I'd like to use the LFS build to > bootstrap a native toolchain using the LFS toolchain packages, which now > require a c++ host build enviornment (I've got one but it predates the > C++ 2013 standard and uClibc++ is a bit creaky and modern gcc is > generally crotchety and evil...) > > Sigh. I should just do that. (Todo list status: runneth over.) > > Did I mention I get on a plane to the west coast tomorrow, to speak at > Linux Plumber's? (A toybox talk in a microconf, and j-core panel for... > either Linuxcon or Plumber's, I can't tell the difference anymore. Thing > the Linux Foundation is doing.) > >> HTH, >> Isaac Dunham > > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
