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.
(Of those, 10 also have a variant that starts with "+" rather than "-".)
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)
> 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've lumped iftop in with top, iotop, and a second pass at vmstat. Ala
> "there's probably some shared infrastructure here, but I'm not sure
> exactly what yet."
>
> It's also shared with less, and the draw_tail() stuff in hexedit.c for
> doing utf8 fontmetrics on strings needs to be genericized into
> lib/interestingtimes.c and then I need to figure out a callback
> infrastructure to escape unprintable characters since that's not done
> consistently between contexts. And then "watch" needs to get its output
> washed through that too... (I.E. doing this right means utf8 support
> from day one...)
>
> (Sigh. I haven't even done the cleanup pass to get the various manual
> tcsetattr() calls using set_terminal() where appropriate.)
>
> > ls
> > -- making progress on the adb/CTS side of things. hopeful we can flip
> > the switch this month.
>
> Let me know if I need to fix anything else there. (The strwidth() in
> there might need to get pulled into the above general fontmetrics stuff,
> but for the moment it should work as-is and handle utf8 names.)
>
> > log
> > nandread
> > newfs_msdos
> > uptime
> > -- ???
>
> I think uptime's good? (Matches ubuntu, anyway.)
But not android.
> 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)
...
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).
[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.
HTH,
Isaac Dunham
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
