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